home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!biosci!agate!apple!mumbo.apple.com!gallant.apple.com!cheryl
- From: cheryl@gallant.apple.com (Cheryl Lins)
- Newsgroups: comp.lang.modula2
- Subject: Re: Oberon vs Modula-2
- Summary: Forward refs to base types
- Message-ID: <1992Nov23.174129.25457@gallant.apple.com>
- Date: 23 Nov 92 17:41:29 GMT
- References: <1992Nov21.095307.19198@neptune.inf.ethz.ch>
- Organization: Apple Computer Inc, Cupertino, CA
- Lines: 35
-
- 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".
- >
- >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.
- >
-
- Of course, it's legal. It's just not what the programmer intended :-)
- The "c" referred to in "b = POINTER TO c" is the record structure declared in
- the outer scope. So obviously, using indexing on a record generates an error
- in >>p[1]<<.
-
- --
- Cheryl Lins Oberon Paladin lins@apple.com
- "Beware the following code - I've only proven it correct, not tested it" Knuth
-