home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / modula2 / 1422 < prev    next >
Encoding:
Text File  |  1992-11-20  |  4.3 KB  |  123 lines
  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!ira.uka.de!math.fu-berlin.de!news.belwue.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: <1992Nov20.125458.25797@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: <9211091022.A01745@MAIL.CASI.NASA.GOV> <5897@balrog.ctron.com> <BEVAN.92Nov18195812@tiger.cs.man.ac.uk>
  10. Date: Fri, 20 Nov 92 12:54:58 GMT
  11. Lines: 110
  12.  
  13. In article <BEVAN.92Nov18195812@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
  14. > In article <1992Nov13.100154.6167@informatik.uni-ulm.de> borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
  15. > 
  16. >    Don't forget that Oberon still needs less than 20 pages of language
  17. >    description.
  18. > 
  19. > Maybe be so, but it doesn't include a formal definition of the context
  20. > constraints (static semantics if you will) nor the dynamic semantics.
  21. > You may think it doesn't require either, however I've personally
  22. > struggled to make sense of the typing rules in the appendix (some of
  23. > which IMHO are redundant!) in an implementaion of a Oberon-2 front
  24. > end.  I found myself having to write bits of code and try them out
  25. > using the ETH compiler to see what (if any) errors it produced.
  26.  
  27. The typing rules in the appendix are in some cases redundant -- that's
  28. probably the reason why they have been put into an appendix.
  29.  
  30. It's always dangerous to follow foreign compilers (even those from ETH)
  31. because they probably never match the Oberon report exactly.
  32.  
  33. Here an example, following program is perfectly legal Oberon text
  34. but rejected by the Sparc Oberon System from ETH Zurich:
  35.  
  36. (* CLASS=CONFORMANCE *)
  37. MODULE t03;
  38.  
  39.    TYPE
  40.       c = RECORD a, b: INTEGER END;
  41.  
  42.    PROCEDURE e;
  43.       TYPE
  44.          b = POINTER TO c;
  45.          c = ARRAY 3 OF CHAR;
  46.       VAR
  47.          p: b;
  48.  
  49.    BEGIN (* e *)
  50.       p^[1] := "x";
  51.    END e;
  52.  
  53. END t03.
  54.  
  55. The compiler complains at the designator >>p^[1]<< that
  56. "indexed variable is not an array".
  57.  
  58. On the other hand, checking the ETH compiler may be a good idea,
  59. especially in those cases where the reports will be later adapted to
  60. their implementations. Examples:
  61.  
  62. (1)    The Oberon report published in Software Practice & Experience
  63.     contains two features which has been dropped in later versions:
  64.     (a) You may pass an extended pointer to a VAR-parameter, e.g.
  65.  
  66.         TYPE T0 = RECORD END; P0 = POINTER TO T0;
  67.          T1 = RECORD (T0) END; P1 = POINTER TO P1;
  68.         VAR p1: P1;
  69.  
  70.         PROCEDURE p(VAR p: P0); BEGIN ... END p;
  71.  
  72.         (* ... *)
  73.         p(p1);
  74.  
  75.     (b) ARRAY OF BYTE may be a call-by-value parameter
  76.     I doubt that they have ever implemented these features.
  77.  
  78. (2)    The Oberon report (ETH report 111, not Oberon-2!) declares in
  79.     9.1 that "The type of the expression must be included by the
  80.     type of the variable, or it must extend the type of the
  81.     variable."
  82.     This has been "clarified" in ETH report 160 (Oberon-2) in
  83.     the above mentioned appendix A: "An expression e of type Te
  84.     is assignment compatible with a variable v of type Tv if
  85.     one of the following conditions hold: ... 3. Te and Tv
  86.     are record types and Te is an extension of Tv and the
  87.     dynamic type of v is Tv.
  88.  
  89. (2) means that
  90.  
  91. MODULE RecAssignment;
  92.  
  93.    TYPE T0 = RECORD END;
  94.         T1 = RECORD (T0) END;
  95.    VAR
  96.       t1a, t1b: T1;
  97.  
  98.    PROCEDURE AssignIt(VAR ta, tb: T0);
  99.    BEGIN
  100.       ta := tb; (* statically the same type and ... *)
  101.    END AssignIt;
  102.  
  103. BEGIN
  104.    AssignIt(t1a, t1b); (* ... dynamically the same type *)
  105. END RecAssignment;
  106.  
  107. is perfectly legal in Oberon but not in Oberon-2. But, of course,
  108. this feature was never implemented in ETH compilers (tell me if
  109. I'm wrong here).
  110.  
  111. In summary, Oberon and Oberon-2 are (at least for ETH) research
  112. projects and, thus, subject to changes and development. So, you've to
  113. decide whether you want to be ETH-compatible or close to one of the
  114. reports. Nevertheless, there are still less questions open in
  115. these 18 pages (Oberon) or 26 pages (Oberon-2) than in any
  116. alternative 600-pages document (at least for me).
  117.  
  118. --
  119. _______________________________________________________________________________
  120.  
  121. Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
  122. Internet: borchert@mathematik.uni-ulm.de
  123.