On 21 Jul 2006 at 3:51, Waldek Hebisch wrote:
- GPC documentation of "--enable-keyword" probably could be improved.
the "--enable-keyword" and "--disable-keyword" are _not_ intended to create a new dialect.
I agree that the manual is confusing, because it says in Chapter 9:
A dialect option turns off all keywords that do not belong to this dialect. Besides, any keyword can be enabled and disabled with the compiler options '{$enable-keyword}' and '{$disable-keyword}'.
...which, to me, says that a general dialect option may be chosen and then selectively extended or restricted with enable/disable.
Rather, they are intended as a help to avoid conflicts betwen identifiers and keywords....
I understand.
However, "--enable-keyword" just causes GPC to recognize given keyword, but otherwise do not influence the accepted language. Since by default all keywords are allowed and dialect choice just rejects constucts outside given dialect, "--enable-keyword" in fact can not enable a new construct -- it can only turn on previously disabled keyword.
I am confused by this. In test program "fjf733e.pas", we have:
{$enable-keyword pow} {$classic-pascal}
program fjf733e (Output);
begin if 2 pow 3 = 8 then WriteLn ('OK') else WriteLn ('failed') end.
This works, but why does it work? "pow" is an operator, and "asm" is a statement keyword, but why does that matter? It appears to me that this changes the dialect from CP to CP-plus-pow-from-EP. I don't understand why:
{$enable-keyword pow}
works, but:
{$enable-keyword asm}
does not work. Shouldn't the above program give "error: `pow' is an extension of Extended Pascal"?
In particular, builtin routines remain effectively disabled (and "ParamCount" is a routine (function)). "Cardinal" works since it is a type.
This also is confusing. In the presence of a language restriction, some predefined identifiers may be enabled (types), but others (built-in routines) cannot. Some keywords ("pow", "attribute") may be enabled, but others ("asm") cannot.
I am not sure if we should change what GPC is doing.
I believe that gpc should either allow "enable" only if a prior "disable" has been done, or allow "enable" without restriction, or document the specific cases where "enable" is allowed. The first option would be your original intent. The second would be most flexible. The third would at least eliminate the confusion where some "enables" are allowed and others are not.
...for keywords things are more tricky: a set of dialects in which a constuct is valid may be smaller then set of dialects in which keywords involved in the constuct are valid so we still need dialect checks.
Are you thinking of cases such as "packed array" is CP, but "packed 0..3" is not? Or "a and b" is CP, but "a and 1" is not?
So, I am not sure how useful would be ability to enable all constructs involwing given keyword.
The reason I was trying to restrict the dialect and then enable certain keywords and predefined identifiers is that changing the dialect from EP to GP changes the semantics of some EP constructs. For instance, changing to GP means that strings are no longer padded for comparisons, so:
var s : packed array [1..6] of char; [...]
s := 'GPC'; if s = 'GPC' then ...
...fails. Also:
var i, j: integer; [...]
i := 1; j := 2; writeln (i, j);
prints "12". So I cannot simply write EP with a few extensions; I must also remember all of the semantic changes that go along with selecting GP.
There are two alternate ways I can accomplish this:
1. Choose the GP dialect and either program around the semantic changes ("if s = 'GPC ' then") or use compiler directives to restore EP semantics ("{$no-exact-compare-strings}").
2. Choose the EP dialect and bracket each extension with "{$gnu-pascal}" and "{$extended-pascal}".
But if I could choose EP and selectively enable the extensions, it would be simpler, and it would document at the start of the source file exactly what extensions were used.
Thank you for your detailed explanations.
-- Dave