Node:Parsing keywords, Next:Parsing subranges, Previous:Language definition, Up:Internals

### So many keywords, so many problems ...

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:

- If a dialect option is set, only keywords of the specified dialect are enabled. All possible keywords, together with their dialects, are defined in `predef.h`. However, compiling with dialect options is usually not recommended, so this is no good general solution.
- The user can turn off individual keywords using the compiler directive `{$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.
- The parser used to enable and disable keywords in certain syntactic contexts. However, this was rather fragile since it interacts with the parser's read-ahead, and it requires attention on every related change in the parser. Therefore, this mechanism was removed.
- Many of the problematic keywords are now treated as "weak". This means, they are only recognized as keywords if no current declaration of this name exists. However, so that this can work, it must be possible to create new declarations of this name in the first place - at this point, no declaration exists yet, so the name is recognized as a keyword.

  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:

- attribute as a weak keyword:
- external as a weak keyword:
- forward near far:
- implementation constructor destructor operator uses import initialization:

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.