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) |
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
Return to the
comp.compilers page.
Search the
comp.compilers archives again.