On Wed, 23 Apr 1997, Jakob Heinemann wrote:
Peter Gerwinski wrote:
According to Frank Heckenbach:
[...] However, the following still doesn't work (if it's already/still on the bug list, please ignore):
PROGRAM x; CONST n:1..16=6; {"subrange bounds are not of the same type"} BEGIN END.
Is this really a bug??? Extended Pascal allows expressions as the upper bound of a subrange. In this case, the expresson "16 = 6" (with the Boolean value "false") is the upper bound - which is indeed not of the same type as the lower bound "1".
Hi folks...
I think the way to solve this is to implement some context sensitivity to the parser, but even that does not solve all problems, if not introduce new ones :-)
This is kind of hard to do in the LALR(1) parsers like yacc and bison, and did not figure out any easy way to do it so I decided to do it "later".
Anyway, it is not possible to automatically decide that constructs like the following are invalid, like can be seen from the pascal boolean subrange variable declaration:
foo : false .. 16=16;
If the decicion of the parse tree is based on the fact that the resulting program would otherwise be syntactically incorrect, the parsing could be done more cleverly, which is required in the following:
foo_error : 1 .. 16 = 15;
Then it remains the problem how to interpret the following:
foo_problem : false .. true = false;
Because that can be interpreted either as an initialized or uninitialized subrange.
Extended pascal does require that both bounds of a subrange can be arbitrary expressions. In GPC (as far as I recall) only the lower bound can be an expression, the upper bound needs to be constant, because I could not find any easy way to prevent the massive amounts of conflicts, no matter how I tried.
Anyone who really knows how to hack parsers interested in this one?
Juki jtv@hut.fi