Re: problems with identifiers and keywords...

glen herrmannsfeldt <gah@ugcs.caltech.edu>
24 Oct 2004 23:45:02 -0400

          From comp.compilers

Related articles
problems with identifiers and keywords... micha-1@fantasymail.de (Micha) (2004-10-21)
Re: problems with identifiers and keywords... cfc@shell01.TheWorld.com (Chris F Clark) (2004-10-23)
Re: problems with identifiers and keywords... gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-10-24)
Re: problems with identifiers and keywords... clint@0lsen.net (Clint Olsen) (2004-10-25)
Re: problems with identifiers and keywords... cfc@shell01.TheWorld.com (Chris F Clark) (2004-11-02)
Re: problems with identifiers and keywords... gah@ugcs.caltech.edu (glen herrmannsfeldt) (2004-11-06)
Re: problems with identifiers and keywords... wclodius@lanl.gov (2004-11-06)
Re: problems with identifiers and keywords... wyrmwif@tsoft.org (SM Ryan) (2004-11-07)
Re: problems with identifiers and keywords... vbdis@aol.com (2004-11-07)
[21 later articles]
| List of all articles for this month |
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Newsgroups: comp.compilers
Date: 24 Oct 2004 23:45:02 -0400
Organization: Comcast Online
References: 04-10-148 04-10-170
Keywords: lex, parse, practice
Posted-Date: 24 Oct 2004 23:45:02 EDT

Chris F Clark wrote:


(small snip)


> And, while I rarely have cause to disagree with our moderator, this is
> one case where I do. The lexical hack of returning an identifier in
> some cases and a keyword in others [this is often implemented using
> lexer states (in LEX or lexer classes in Yacc++)] while time tested
> *may not* be the best solution for your problem.


> The lexer state solution involves coordination between the lexer and
> the parser. In particular, the parser must tell the lexer whether in
> "this context" a keyword is expected or an identifier is
> expected. There are several problems with coordinating the lexer's
> state with the parser's context.


(much bigger snip)


Two languages which have no reserved words and a reasonable number of
compilers are Fortran and PL/I. Traditionally Fortran has made it
even harder by not making blank space significant, yet the process for
writing Fortran parsers is well understood.


Some of the old Fortran favorites are the assignment statement


              DO 1 I=1.10


and the DO loop statement


              DO1I=1,10


then there is the legal FORMAT statement


2 FORMAT(I10)


and assignment statement


2 FORMAT(I10)=20


PL/I, at least, makes blanks significant but you can have
fun with statements such as


IF IF=THEN THEN THEN=ELSE; ELSE ELSE=IF;


It might be that LEX/YACC isn't enough for either language.


-- glen
[Having written a couple of Fortran parsers I can report that I needed
to write a custom lexer but yacc was quite adequate for parsing.
Dealing with Fortran isn't hard once you realize you have to make a
prepass over each statement to figure out whether it's an assignment
or not and to mark the literal strings. The prepass is a little
tricky, e.g. the format example above, and this (using a common type
extension) does not include the four-character Hollerith constant
ELLO:


    REAL*4HELLO


I get the impression that there have only been two parsers written
for PL/I, the IBM one at Hursley and the Freiboughouse one originally
for Multics. I dunno how they work. -John]



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.