🚀 go-pugleaf

In article <1992Nov22.125424.28252@neptune.inf.ethz.ch>, templ@inf.ethz.ch (Josef Templ) writes:
> > 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.
> 
> S. Bevan writes
> > 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? 
> 
> IMHO, our interpretations are exactly the same.
> It is the interpretation that evolves naturally from "single pass compilation".
> Unfortunately, the current report allows a different interpretation
> because it does not restrict the forward declaration rule to
> forward declarations. In this sense, the report is ambigous.
> It does not specify which c is to be taken as the pointer base type.
> If you switch b and c, there is no ambiguity even in the current report.

Hm, perhabs we are using different reports. The ETH language reports
change too often to be always up to date.

In the latest yellow report I received from ETH (report 111 from
September 1989) I find following statements in section 4 (declarations
and scope rules):

The scope extends textually from the point of the declaration to the end
of the block (procedure or module) to which the declaration belongs and
hence to which the object is local. The scope rule has the following
amendments:

   1. If a type T is defined as POINTER TO T1 (see 6.4), the identifier
      T1 can be declared textually following the declaration of T,
      but it must lie within the same scope.

I don't see any interpretation which allows the declaration "b = POINTER TO c"
to be bound to the previously declared type "c". The amendments take
precedence over the statements before (that follows clear from the text)
and, consequently, I may declare the referenced type even if there
exist the same identifier in the outer scope.

This is preferably -- for what reason should my local declarations depend
from the outer scope if they don't need the outer scope?

And there is no difficulty in implementing this definition in a
1-pass compiler: view all pointer declarations as forward-declarations
and delay the association to the first procedure or the body of
the procedure or module of the scope. Procedure declarations may not
be followed by other declarations -- so we don't come in to trouble.

-- 
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de