Re: keywords and identifiers..

Chris F Clark <world!cfc@uunet.uu.net>
16 Sep 1999 01:57:37 -0400

          From comp.compilers

Related articles
keywords and identifiers.. ash_nw@my-deja.com (1999-09-11)
Re: keywords and identifiers.. wmm@fastdial.net (1999-09-16)
Re: keywords and identifiers.. world!cfc@uunet.uu.net (Chris F Clark) (1999-09-16)
Re: keywords and identifiers.. webid@asi.fr (Armel) (1999-09-16)
Re: keywords and identifiers.. jerrold.leichter@smarts.com (Jerry Leichter) (1999-09-20)
Re: keywords and identifiers.. genew@shuswap.net (1999-09-24)
Re: keywords and identifiers.. delta-t@t-online.de (Leif Leonhardy) (1999-09-27)
| List of all articles for this month |

From: Chris F Clark <world!cfc@uunet.uu.net>
Newsgroups: comp.compilers
Date: 16 Sep 1999 01:57:37 -0400
Organization: The World Public Access UNIX, Brookline, MA
References: 99-09-045
Keywords: parse

> Had a small question concerning keywords/identifiers and possibly
> languages in general. Are there languages which allow a keyword to
> be accepted as an identifier. . . .


Our moderator replied:
John> Yes, lots of languages don't reserve their keywords, with Fortran and
John> PL/I being among the better known examples. One approach is to concoct
John> an extended syntax with rules like this that permit keywords to act as
John> symbols.
John>
John> symbol: SYMBOL | IF | THEN | ELSE | ...
John>
John> but that usually ends up being hopelessly ambiguous.


Actually, the ambiguity is not usually as hopeless as it might seem.
In fact, the next installment of the SIGPLAN Notices column, Keywords
part II, deals with the process of removing the ambiguities.


Essentially, everywhere the parser generator fails is a place where
one of the keywords has its reserved meaning. For example, "if" will
fail as an identifier at the beginning of statements because the "if"
keyword marks the beginning of an "if" statement.


The solution in those cases is to make another "symbol" rule that has
all the keywords execpt "if" in it and use it in the rules that
conflict with the "if" statement rule (part 1). You can still allow
"if" to be a non-keyword in that context by making special copies of
the conflicting rules that handle the "if" non-keyword case also (part
2). Something like the following:


stmt: "if" expr "then" stmt
        | symbol "=" expr // conflicts with "if" keyword above
        ;


is changed to:


stmt: "if" expr "then" stmt
        | symbol_not_if "=" expr // part 1, remove if from symbol here
        | "if" = expr // part 2, add special rule to handle if non-keyword here
        ;


BTW, you have to do a little more (i.e. left factor) if you want the
grammar to be LL(1).


Hope this helps,
-Chris


PS. I think John's point was as much to the issue of allowing too much
freedom quickly leads to unparseable grammars, both for machines and
for humans. The famous C++ rule that "if it looks like a declaration,
it is a declaration" is a good example. You need infinite lookahead,
backtracking, or an equivalent technique to parse such things and some
of the example cases even surprise programmers until they think about
them carefully. Surprise is not a good language design feature.
Thus, you want to think carefully before you let all your keywords be
symbols. It might actually make your language more confusing.


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. CompuServe : 74252,1375
3 Proctor Street voice : (508) 435-5016
Hopkinton, MA 01748 USA fax : (508) 435-4847 (24 hours)
------------------------------------------------------------------------------
Web Site in Progress: Web Site : http://world.std.com/~compres


Post a followup to this message

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