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".
This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it - just like with the "dangling else" problem. Since I am a complete beginner with parsers (no theoretical knowledge; my only experience with bison relates to GPC) I would be glad if somebody could help me with this.
{The same with "var ...=...", ok with "var ... value ..."}
Strange. On my box, it works with `value'.
Then, a very small problem:
I have a Pascal program (let's say foo.pas) that uses some units. [...] If I compile it with "gpc foo.pas bar.c", it works fine. But if I do "gpc bar.c foo.pas", it doesn't ("Undefined references" to the C functions).
I think that's intended: The GNU linker is a one-pass linker which needs the "lowest" unit in the most right position of the command line. (I think. I don't really know.;-)
In the latter situation also the file foo.gpc is left.
That's indeed a bug. Thanks for the report.
Greetings,
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970420] - http://home.pages.de/~gnu-pascal/ [970125]
CONST n:1..16=6; {"subrange bounds are not of the same type"}
... This is a known shift/reduce conflict in the parser. In principle it should be possible to tell bison to shift it rather than to reduce it -
Actually, bison (and yacc) automatically do a shift for a shift/reduce conflict. That is why the error. It shifts the = on the parse stack to get a handle of E=E and that is considered the upper bound. What you want here is to force the reduce, so the 16 is reduced to an expression and the = remains as part of the "const x = value;" By forcing the reduce then the construct "CONST N : false .. 1 = 1 = false;" produces a syntax error. But, you can still do this by "CONST N : false .. (1 = 1) = false;"; So I would say that you do want to force the reduce and make equals have to be parenthesized to get comparison.
To get it, you need a fake precedence and use the "%prec" construct on the proper rule in the grammar. If you can't figure it out, I'll get a copy of the alpha and try to get a patch to you.
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".
Its not that easy to tell what your code means, not even for people, Franks intention is easily interpreted in the way Peter does and then of course its obvious that the compiler should protest. Thinking of extended Pascals expression evaluation its a matter of operator precedence. Which comes first .. or = in a constant declaration.
I Suppose Frank intended to have a specific value of a subrange as a constant, but really this is not a good code example, for making good use of constants in a program you should make an explicit type declaration, and though I have not tried it this should work:
PROGRAM x; TYPE short_range_type = 1..16; (* here some integer maths could be applied on the bounds *) CONST somewhere_in_between_c : short_range_type = 6; VAR a_value : short_range_type; BEGIN a_value := 4; if a_value < somewhere_in_between_c (* comparison with values of same type*) then writeln('Yeah this is working'); END.
/Jakob :)
Longtimepascalhackerthatnowadayshackalotada. Ericsson Saab Avionics AB, Linköping, Sweden. mailto:Jakob.Heinemann@ericsson.com
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
-
Jakob Heinemann -
Jukka Virtanen -
Peter Gerwinski -
Phil Nelson