Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site lanl-a.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxl!houxm!hogpc!houti!ariel!vax135!floyd!cmcl2!lanl-a!jlg From: jlg@lanl-a.UUCP Newsgroups: net.lang Subject: Re: Lexical analyzers and parsers Message-ID: <7033@lanl-a.UUCP> Date: Thu, 10-May-84 15:00:29 EDT Article-I.D.: lanl-a.7033 Posted: Thu May 10 15:00:29 1984 Date-Received: Sat, 12-May-84 12:24:45 EDT References: <1632@tekig1.UUCP>, <174@ccieng2.UUCP> Organization: Los Alamos National Laboratory Lines: 35 iiiii The statement IF ( I.EQ.J ) 50,60,70 Normally parses to ... which is illegal in Fortran, the IF is identified when the point is found, and is NOT delayed until the first comma is shifted. An alternate way of parsing Fortran is to assume that every statement begins with a keyword (all but the assignment statement do). If a keyword is not found, then assume it's an identifier. This means you only have to backtrack when an identifier has a prefix that exactly matches a keyword. For example: IF(X.EQ.Y)GOTO 50 ABC=3. DONT(55)=1. Backtrack is only required for the third line since it is first parsed as ... which causes an error. Backtrack can then find the correct parse: This method of parsing is as fast as parsing a language with reserved keywords and significant blanks except for those statements which cause the backtrack. Since most identifiers don't begin with a keyword (many keywords are too long to be mistaken for identifiers anyway), the speed penalty is only rarely paid. Don't think from this that I'm in favor of ignoring blanks, I'm not. There are ambiguities caused by ignoring blanks that can't be resolved by any parsing scheme. Besides, the complexity of coding a parser that can backtrack is unnecessary for languages with significant blanks.