home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.modula2
- Path: sparky!uunet!math.fu-berlin.de!news.belwue.de!news.uni-ulm.de!theorie!titania.mathematik.uni-ulm.de!borchert
- From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
- Subject: Re: Oberon vs Modula-2
- Message-ID: <1992Nov23.063239.4580@informatik.uni-ulm.de>
- Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting)
- Nntp-Posting-Host: titania.mathematik.uni-ulm.de
- Organization: University of Ulm, SAI
- References: <1992Nov22.125424.28252@neptune.inf.ethz.ch>
- Date: Mon, 23 Nov 92 06:32:39 GMT
- Lines: 63
-
- 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
-