Re: problems with identifiers and keywords...

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:


>Another problem is that many compilers aren't good at giving a
>meaningful diagnostic when a keyword is used as an identifier.


Gene Wirchenko <genew@mail.ocis.net> replied (perhaps toungue in cheek):


> My contributions to the world of compilers:
>
> Keyword "KW" is not legal in this context.
...


The problem is not that you get a syntax error, but just the reverse.


If one sees a keyword that may be an identifier in some context where
it can also be a keyword, then the parser has to parse further along a
potentially ambiguous path. Most parser generators are not good at
giving error messages indicating that the problem in the current
position is due to the parser misinterpreting something (while
syntactically valid was) incorrect previously.


The so-called valid prefix property that LL and LR parsers share, is
only a property that there is "some" program that has the preceeding
tokens in it. It is not the property that the "given" program has the
first error at the location specified. The location where an LL or
LR parser detects an error may be past where the error actually
occurs.


For example, if you insert a closing ) somewhere in a program, it is
quite possible that the closing ) is legal at the point inserted. The
next coupld of tokens after the closing ) may be legal also. However,
eventually, the parser will encounter some token that isn't legal.
The parser will identify that token as the error, because that's where
the valid prefix property ceases to hold. The parser probably won't
tell you that if you removed the closing ) several tokens back, that
the error it is reporting is no longer present.


Now, it is possible to make a grammar that allows extra closing )s in
many contexts. However, that just makes the problem harder to find.
The same reasoning applies to keywords. If you make keywords serve
multiple purposes and/or you allow them to be identifiers, you make
the parsing and error recovery job harder. The easiest to report
errors have each keyword occur in exactly one place in a legitimate
program, then if you don't see the keyword where expected or see it
where it is expected, it is an error. The more contexts where a
keyword *might* be valid, the more difficulty your parser/error
recovery with saying that some occurance of a keyword is wrong, and
the more difficult it will be to print out a correct and informative
error message.


Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

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