Grant Jacobs wrote:
While it (probably!) won't affect me, I prefer that people use the second to make an explicit statement about what they are trying to achieve, although it'd be nice to have it as a compiler directive so that it can be placed within the source as so to make the source self-documenting in this respect, e.g.
{$pascal-dialect extended-pascal}
{$extended-pascal}
{$disable-keyword operator}
This does already work (though vice versa, since once EP mode is on, compiler directives are forbidden -- well, warned only, actually).
(And this particular combination is redundant, since `operator' is no EP keyword (only PXSC), so it wouldn't be active in EP mode, anyway.)
While others might argue that this is not portable, at least it reminds you what you intended!
Sure. If you want to be portable to, say, EP or BP, just use this dialect option (globally) and all keywords are set automatically.
The whole issue mainly comes up when using no dialect option.
(The disadvantage is that it'd need to be in every source file and you might get issues if the dialect started differing in the different source files!)
This should be no problem. Even turning keywords on/off or switching dialects within one source file should work (though it isn't recommended at all).
I think the whole idea of interpreting the meaning of an identifier in context is a shade dodgy (see my other post today mentioning simple rules for determining user identifier and predefined keyword conflicts). Although clunky in many ways, I thought one of the original things in Pascal was that keywords just were keywords, no matter where they were found.
Well, I guess this ended already with the introduction of EP:
: ISO/IEC 10206:1990(E) Annex B (Informative) : : Incompatibilities with Pascal standards : : Programs that conform to the existing Pascal standards ISO 7185, : BS 6192, and ANSI/IEEE770X3.97- 1983 may need to have some : identifiers changed in them because of the addition of new : wordsymbols in Extended Pascal. The new word-symbols that have : been added to Extended Pascal are: : : and_then only protected bindable or_else qualified export : otherwise restricted import pow value module
The most important one is surely `value' which is often used as an identifier in many CP (and also BP etc.) programs.
Talking of the default GPC mode, it must be EP compatible, so `value' must be a keyword. If we make it so unconditionally, it will break much existing CP and BP code, requiring it to be changed or compiled with dialect options (which we generally don't recommend, since many useful extensions aren't available then).
So, making them conditional keywords helps a lot there. As you said, making this dependent on the context is problematic. That's why I suggested the new approach: It is an identifier if a declaration of this name exists, and a keyword otherwise. -- Well, almost: Of course, it must also be an identifier in those places where new declarations are made (otherwise it would be impossible to make such a declaration). So it is still context dependent, but much less so than before (and, as it happens, support for this way already exists in GPC's parser, since it's the same way that some special predefined identifiers are handled, e.g. `WriteLn' with its special syntax which loses its special properties when redefining it, and after it has been redefined, i.e. just the same I proposed for the keywords). This approach will fail with keywords that would conflict in those places where new identifiers can be defined. I'll have to check this, but I hope it won't be too many ...
BTW, as I said the other day, I'm quite critical of the addition of new keywords in general -- e.g., instead of `value' for type initialization it seems to be possible to use `:=' (an existing symbol, and no word at all) like VAX Pascal apparently does. In other cases, a combination of existing keywords can do nicely (such as EP does in the form of `to begin do' and `to end do' -- instead of introducing new keywords there which Delphi does; OTOH, EP introduces `and_then' and `or_else' instead of using `and then' and `or else', which GPC also allows, and which don't cause any conflicts). So I'd like the ideal original world where "keywords just were keywords", but unfortunately that's out of our control if we want to be compatible ...
That said, there must be pragmatic cases where it'd be nice to avoid conflicts in legacy code (like mine! :-) ). Perhaps this should of thing by default should _not_ take place unless the user explicitly asks for it to happen to specific identifiers, e.g.
{$allow-user-identifier static}
(Note this doesn't disable the keyword)
and/or
{$context-dependent static}
for the really sticky cases only (and only if anyone ever implements it!).
I don't see how it would improve anything -- one still would need a special option to compile, say CP/BP code which uses `Value' as an identifier.
Frank