Re: How to parse keywords that can be used as identifiers?

Jerry Leichter <leichter@smarts.com> writes:


> With modern languages, much of the semantics of the language is not
> in the statements themselves, but in the libraries. For typical
> object- oriented languages, the descriptions of the libraries are
> many times the size of the language descriptions! However, no one
> proposes that the names of library classes, much less their members
> be reserved! If it's so important to reserve the keywords, why not
> the library names?


Actually, AFAIK, the C++ draft standard says that reusing names from the std
namespace leads to undefined behaviour. Now this isn't "reserved" in the
same sense (the compiler is not required to diagnose), but as far as the end
result goes it's pretty much the same thing. You _are_ supposed to know the
whole standard library if you use the language.


> As PL/I long ago demonstrated, it's quite possible to define a
> reasonable programming-language grammar with *no* reserved words. It's
> quite true that "bad examples" like the famous:
>
> IF IF = THEN THEN THEN = ELSE ELSE ELSE = END END
>
> are then possible. So? Reasonable programmers won't write such things;
> few programmers will use a keyword *of which they are aware* as a
> variable name. But what's the big deal if they use, say, UNSPEC as a
> variable name, even if an advanced PL/I programmer knows that that's a
> build-in pseudo-function (or whatever it's called)?


One problem (admittedly of a different nature) is that allowing this makes
implementation much harder. Therefore, there'll be fewer and more expensive
implementations, and the organisations responsible for the few
implementations will wield near monopoly power over the language. In the
end, users may lose.


--
Ian T Zimmerman <itz@rahul.net>
[Previous messages suggest that parsing such languages isn't actually all that
much harder so long as you have tools that can backtrack. -John]
--

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