🚀 go-pugleaf

In article <1992Nov21.095307.19198@neptune.inf.ethz.ch> templ@inf.ethz.ch (Josef Templ) writes:
   A. Borchert writes:
   > Here an example, following program is perfectly legal Oberon text
   > but rejected by the Sparc Oberon System from ETH Zurich:
   > 
   > (* CLASS=CONFORMANCE *)
   > MODULE t03;
   >    TYPE c = RECORD a, b: INTEGER END;
   >    PROCEDURE e;
   >       TYPE b = POINTER TO c;
   >          c = ARRAY 3 OF CHAR;
   >       VAR p: b;
   >    BEGIN (* e *)
   >       p^[1] := "x";
   >    END e;
   > END t03.
   > The compiler complains at the designator >>p^[1]<< that
   > "indexed variable is not an array".

   Section 4 (Declarations and Scope rules) of the Oberon-2 Report:
     The scope of an object x extends textually from the point of its declaration 
     to the end of the block (module, procedure, or record) to which the 
     declaration belongs and hence to which the object is local.

   and in the same section:
     A type T of the form POINTER TO T1 (see 6.4) can be declared before
     the scope of T1. In this case, the declaration of T1 must follow in
     the same block to which T is local;

   I think this is an ambiguity in the language definition.
   The forward declaration rule should be explicitely restricted to
   the cases where T1 is not visible at the point of the forward declaration.
   Anyway, the intention is that the above program is neither legal
   Oberon nor legal Oberon-2.

I'd call that more than an ambiguity.  My _interpretation_ of the
rules (and the one I implemented) was that the above program was
invalid, but that if you switched the order of "b" and "c" it would be
valid.  Is the above (jt) interpretation going to be made official at
some point? 

bevan