home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / modula2 / 1429 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  2.2 KB
  1. Path: sparky!uunet!spool.mu.edu!agate!doc.ic.ac.uk!uknet!mucs!m1!bevan
  2. From: bevan@cs.man.ac.uk (Stephen J Bevan)
  3. Newsgroups: comp.lang.modula2
  4. Subject: Re: Oberon vs Modula-2
  5. Message-ID: <BEVAN.92Nov21180332@beluga.cs.man.ac.uk>
  6. Date: 21 Nov 92 18:03:32 GMT
  7. References: <1992Nov21.095307.19198@neptune.inf.ethz.ch>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Department of Computer Science, University of Manchester
  10. Lines: 42
  11. In-reply-to: templ@inf.ethz.ch's message of 21 Nov 92 09:53:07 GMT
  12.  
  13. In article <1992Nov21.095307.19198@neptune.inf.ethz.ch> templ@inf.ethz.ch (Josef Templ) writes:
  14.    A. Borchert writes:
  15.    > Here an example, following program is perfectly legal Oberon text
  16.    > but rejected by the Sparc Oberon System from ETH Zurich:
  17.    > 
  18.    > (* CLASS=CONFORMANCE *)
  19.    > MODULE t03;
  20.    >    TYPE c = RECORD a, b: INTEGER END;
  21.    >    PROCEDURE e;
  22.    >       TYPE b = POINTER TO c;
  23.    >          c = ARRAY 3 OF CHAR;
  24.    >       VAR p: b;
  25.    >    BEGIN (* e *)
  26.    >       p^[1] := "x";
  27.    >    END e;
  28.    > END t03.
  29.    > The compiler complains at the designator >>p^[1]<< that
  30.    > "indexed variable is not an array".
  31.  
  32.    Section 4 (Declarations and Scope rules) of the Oberon-2 Report:
  33.      The scope of an object x extends textually from the point of its declaration 
  34.      to the end of the block (module, procedure, or record) to which the 
  35.      declaration belongs and hence to which the object is local.
  36.  
  37.    and in the same section:
  38.      A type T of the form POINTER TO T1 (see 6.4) can be declared before
  39.      the scope of T1. In this case, the declaration of T1 must follow in
  40.      the same block to which T is local;
  41.  
  42.    I think this is an ambiguity in the language definition.
  43.    The forward declaration rule should be explicitely restricted to
  44.    the cases where T1 is not visible at the point of the forward declaration.
  45.    Anyway, the intention is that the above program is neither legal
  46.    Oberon nor legal Oberon-2.
  47.  
  48. I'd call that more than an ambiguity.  My _interpretation_ of the
  49. rules (and the one I implemented) was that the above program was
  50. invalid, but that if you switched the order of "b" and "c" it would be
  51. valid.  Is the above (jt) interpretation going to be made official at
  52. some point? 
  53.  
  54. bevan
  55.