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.