Keywords can be potential problems since they are (generally) not available for use as identifiers. Only those keywords that are defined in ISO 7185 Pascal are unproblematic because no valid program should ever use them as identifiers.
To cope with this problem, GPC does several things:
predef.h
. However, compiling with dialect
options is usually not recommended, so this is no good general
solution.
{$disable-keyword}
. This makes sure that every
conflict with a user's identifier can be avoided, but with
extra work on part of the user.
This is solved by listing these keywords in the
new_identifier
rule of the parser. This means, first the
lexer recognizes them as keywords, then the parser “turns them
back” into identifiers. The advantage, compared to explicit
enabling and disabling of keywords, is that bison automatically
finds the places in which to apply the new_identifier
rule,
i.e. treat them as plain identifiers.
Of course, there is a catch. Since the keyword tokens are listed in
new_identifier
, they can conflict with occurrences of the
actual keywords (bison will find such cases as S/R or R/R
conflicts). Such conflicts have to be sorted out carefully.
Fortunately, for many keywords, this turned out quite easy – in
some cases no conflicts at all arose. One especially complicated
example is explained below in detail. If it is not possible to solve
the conflicts for a particular keyword, this keyword cannot be
handled this way.
The following sections describe the most problematic keywords:
These descriptions should make it clear that we're walking on the bleeding edge of what's possible with LALR(1) and lexer tricks. Trying much more will probably increase the complexity to the unmanageable.