🚀 go-pugleaf

In article <BEVAN.92Nov18195812@tiger.cs.man.ac.uk>, bevan@cs.man.ac.uk (Stephen J Bevan) writes:
> In article <1992Nov13.100154.6167@informatik.uni-ulm.de> borchert@titania.mathematik.uni-ulm.de (Andreas Borchert) writes:
> 
>    Don't forget that Oberon still needs less than 20 pages of language
>    description.
> 
> Maybe be so, but it doesn't include a formal definition of the context
> constraints (static semantics if you will) nor the dynamic semantics.
> You may think it doesn't require either, however I've personally
> struggled to make sense of the typing rules in the appendix (some of
> which IMHO are redundant!) in an implementaion of a Oberon-2 front
> end.  I found myself having to write bits of code and try them out
> using the ETH compiler to see what (if any) errors it produced.

The typing rules in the appendix are in some cases redundant -- that's
probably the reason why they have been put into an appendix.

It's always dangerous to follow foreign compilers (even those from ETH)
because they probably never match the Oberon report exactly.

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".

On the other hand, checking the ETH compiler may be a good idea,
especially in those cases where the reports will be later adapted to
their implementations. Examples:

(1)	The Oberon report published in Software Practice & Experience
	contains two features which has been dropped in later versions:
	(a) You may pass an extended pointer to a VAR-parameter, e.g.

	    TYPE T0 = RECORD END; P0 = POINTER TO T0;
		 T1 = RECORD (T0) END; P1 = POINTER TO P1;
	    VAR p1: P1;

	    PROCEDURE p(VAR p: P0); BEGIN ... END p;

	    (* ... *)
	    p(p1);

	(b) ARRAY OF BYTE may be a call-by-value parameter
	I doubt that they have ever implemented these features.

(2)	The Oberon report (ETH report 111, not Oberon-2!) declares in
	9.1 that "The type of the expression must be included by the
	type of the variable, or it must extend the type of the
	variable."
	This has been "clarified" in ETH report 160 (Oberon-2) in
	the above mentioned appendix A: "An expression e of type Te
	is assignment compatible with a variable v of type Tv if
	one of the following conditions hold: ... 3. Te and Tv
	are record types and Te is an extension of Tv and the
	dynamic type of v is Tv.

(2) means that

MODULE RecAssignment;

   TYPE T0 = RECORD END;
        T1 = RECORD (T0) END;
   VAR
      t1a, t1b: T1;

   PROCEDURE AssignIt(VAR ta, tb: T0);
   BEGIN
      ta := tb; (* statically the same type and ... *)
   END AssignIt;

BEGIN
   AssignIt(t1a, t1b); (* ... dynamically the same type *)
END RecAssignment;

is perfectly legal in Oberon but not in Oberon-2. But, of course,
this feature was never implemented in ETH compilers (tell me if
I'm wrong here).

In summary, Oberon and Oberon-2 are (at least for ETH) research
projects and, thus, subject to changes and development. So, you've to
decide whether you want to be ETH-compatible or close to one of the
reports. Nevertheless, there are still less questions open in
these 18 pages (Oberon) or 26 pages (Oberon-2) than in any
alternative 600-pages document (at least for me).

--
_______________________________________________________________________________

Andreas Borchert, University of Ulm, SAI, D-W-7900 Ulm, Germany
Internet: borchert@mathematik.uni-ulm.de