New Alpha _(re)

Wed, 23 Apr 1997 21:49:06 +0200 (MET DST)

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]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)