12.3.1 Conflicts in the Pascal syntax
Some problematic parts of Pascal syntax in various dialects
(see also see Lexer problems):
- BP style initializers for variables (or “typed constants”, as BP
likes to call initialized variables even though they are not
constant) with = rather than value. Problem: It makes
initialized Boolean subrange variable declarations like Foo:
False .. True = False = False ambiguous. They could be interpreted
as Foo: False .. (True = False) = False or Foo: False
.. True = (False = False). This lexer, like BP, chooses the latter
interpretation. To avoid conflicts in the parser, this is done with
the LEX_CONST_EQUAL hack, counting parentheses and brackets
so that in Foo: False .. (True = False) = True the
second = will become the LEX_CONST_EQUAL token.
- BP style array initializers in (, ). When they consist
of a single entry (without an index as required in EP), they
conflict with expressions in parentheses. This is resolved in the
parser using GLR with %dprec, and in the following processing
of initializers.
- Extended Pascal (and many dialects) allow the lower bound of a
subrange declaration to be an arbitrary expression (Standard Pascal
allows only a plain constant). This makes things like var Foo:
(Bar ... hard to parse, since Bar could be part of an
expression in parentheses as the lower bound of a subrange, or the
beginning of an enumeration type declaration. BP can't handle this
situation. In GPC, this is now solved with the GLR parser. In fact,
this case is rather easy to handle for GLR, as it does not even need
%dprec or %merge since the presence or absence of
.. sooner or later makes one alternative fail.
- Delphi's external [libname] [name name] construct
where libname and name can be string expressions. Since
name is not a reserved word, but an identifier,
external name name name can be valid which is difficult to
parse. It could be solved by the parser, by making name a
special identifier whose special meaning is recognized after
external only.