At 10:29 AM +0100 16/3/03, Frank Heckenbach wrote:
I've done this now and analyzed all problematic keywords. Fortunately, most of them could be completely resolved this way. In addition, some of them can even be used as "keywords" (directives) and identifiers in parallel, in particular `forward' (which the Pascal standards require) and `near' and `far' (which BP seems to do, though its documentation says otherwise).
There are only two exceptions:
`Operator' can't be used as a type, untyped constant or exported interface (unless it's disabled as a keyword explicitly or by dialect options). This is because of the following conflict:
type Foo = record end; Operator = (a, b); { enum type }
vs.
type Foo = record end;
operator = (a, b: Foo) c: Foo;
This is not a complete ambiguity, but requires 6 tokens look-ahead to decide whether `operator' is a keyword. That's way too much (IMHO), so since the operator `=' should be definable, we have to make the restriction as stated.
Just out of interest: the use of the word 'operator' in the code I was porting was within a type definition, e.g.
half_exprs = record negate : boolean; operator : operators; case value_type : value_types of int_value : ( int : integer ); string_value : ( str : strings ) end;
Is it easy to reduce the conflict to just when operator is defined as a "plain" type (as in your example) rather than within a record?
A possible further reduction, although a bit ugly, would be that if the user wants to use "operator = ..." as a type, they must place it as the first type definition, e.g.
type Operator = (a, b); Foo = record end;
These two would cover many, but not all cases.
As an aside, it makes me think that the const, type and var section probably could have been designed to have an "end" keyword to avoid this sort of thing (when Pascal was first designed, that is); this isn't a suggestion, just a idle thought. Something like:
const-begin <const declarations> const-end
type-begin <type declarations> type-end
This way later development of new things like operator = ... wouldn't impact on the declaration sections, as they'd have one unique end-point "for all time".
But that's off topic a bit...
Grant