home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / modula2 / 1436 < prev    next >
Encoding:
Text File  |  1992-11-22  |  3.3 KB  |  76 lines

  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!math.fu-berlin.de!news.belwue.de!news.uni-ulm.de!theorie!titania.mathematik.uni-ulm.de!borchert
  3. From: borchert@titania.mathematik.uni-ulm.de (Andreas Borchert)
  4. Subject: Re: Oberon vs Modula-2
  5. Message-ID: <1992Nov23.063239.4580@informatik.uni-ulm.de>
  6. Sender: usenet@informatik.uni-ulm.de (Name for nntp-posting)
  7. Nntp-Posting-Host: titania.mathematik.uni-ulm.de
  8. Organization: University of Ulm, SAI
  9. References:  <1992Nov22.125424.28252@neptune.inf.ethz.ch>
  10. Date: Mon, 23 Nov 92 06:32:39 GMT
  11. Lines: 63
  12.  
  13. In article <1992Nov22.125424.28252@neptune.inf.ethz.ch>, templ@inf.ethz.ch (Josef Templ) writes:
  14. > > MODULE t03;
  15. > >    TYPE c = RECORD a, b: INTEGER END;
  16. > >    PROCEDURE e;
  17. > >       TYPE b = POINTER TO c;
  18. > >          c = ARRAY 3 OF CHAR;
  19. > >       VAR p: b;
  20. > >    BEGIN (* e *)
  21. > >       p^[1] := "x";
  22. > >    END e;
  23. > > END t03.
  24. > S. Bevan writes
  25. > > I'd call that more than an ambiguity.  My _interpretation_ of the
  26. > > rules (and the one I implemented) was that the above program was
  27. > > invalid, but that if you switched the order of "b" and "c" it would be
  28. > > valid.  Is the above (jt) interpretation going to be made official at
  29. > > some point? 
  30. > IMHO, our interpretations are exactly the same.
  31. > It is the interpretation that evolves naturally from "single pass compilation".
  32. > Unfortunately, the current report allows a different interpretation
  33. > because it does not restrict the forward declaration rule to
  34. > forward declarations. In this sense, the report is ambigous.
  35. > It does not specify which c is to be taken as the pointer base type.
  36. > If you switch b and c, there is no ambiguity even in the current report.
  37.  
  38. Hm, perhabs we are using different reports. The ETH language reports
  39. change too often to be always up to date.
  40.  
  41. In the latest yellow report I received from ETH (report 111 from
  42. September 1989) I find following statements in section 4 (declarations
  43. and scope rules):
  44.  
  45. The scope extends textually from the point of the declaration to the end
  46. of the block (procedure or module) to which the declaration belongs and
  47. hence to which the object is local. The scope rule has the following
  48. amendments:
  49.  
  50.    1. If a type T is defined as POINTER TO T1 (see 6.4), the identifier
  51.       T1 can be declared textually following the declaration of T,
  52.       but it must lie within the same scope.
  53.  
  54. I don't see any interpretation which allows the declaration "b = POINTER TO c"
  55. to be bound to the previously declared type "c". The amendments take
  56. precedence over the statements before (that follows clear from the text)
  57. and, consequently, I may declare the referenced type even if there
  58. exist the same identifier in the outer scope.
  59.  
  60. This is preferably -- for what reason should my local declarations depend
  61. from the outer scope if they don't need the outer scope?
  62.  
  63. And there is no difficulty in implementing this definition in a
  64. 1-pass compiler: view all pointer declarations as forward-declarations
  65. and delay the association to the first procedure or the body of
  66. the procedure or module of the scope. Procedure declarations may not
  67. be followed by other declarations -- so we don't come in to trouble.
  68.  
  69. -- 
  70. _______________________________________________________________________________
  71.  
  72. Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
  73. Internet: borchert@mathematik.uni-ulm.de
  74.