According to Oberon's type compatibility rules (as given, for instance,
in Appendix A of "The Programming Language Oberon-2" by Wirth and
Mo"ssenbo"ck), the following program should not compile:

MODULE test;

TYPE
  int = RECORD i : INTEGER END;
  meters = POINTER TO int;
  feet = POINTER TO int;

VAR
  m : meters;
  f : feet;

BEGIN
  m := f;
END test.

Yet, on the three implementations I tried it (MacOberon, MacOberon
Lite, and SPARCOberon), it does not produce a type compatibility
error. Why?

Edgar

--

Purdue University                      
Department of Computer Sciences         +1 (317) 494-6028 (voice)
West Lafayette, IN 47907-1398           +1 (317) 494-0739  (fax)

: MODULE test;
: TYPE
:   int = RECORD i : INTEGER END;
:   meters = POINTER TO int;
:   feet = POINTER TO int;
: VAR
:   m : meters;
:   f : feet;
: BEGIN
:   m := f;
: END test.

: Yet, on the three implementations I tried it (MacOberon, MacOberon
: Lite, and SPARCOberon), it does not produce a type compatibility
: error. Why?

It does the same thing on POWEROberon.

If I remember correctly the compiler in Project Oberon performs
the following tests. ( the sources are on neptune.inf.ethz.ch )
It checks if the pointers are of the same type. If they are not
the same, as in this case, it attempts to test the compatibilty
of the types which the pointer references. In this case it is
the same record so the pointers are said to be compatible. This
is incorrect according to Appendix A. It is testing for
type-extensions too early. It should test the pointers for compatibility,
if this  fails it should test the types, if this succeeds it should
report an error, otherwise should test for assignment compatibility
based on type extension.

This the real meaning of Oops.

Whitney

We seem to have baby ducks everywhere. No error with Extacy either.

Whitney

First of all, let us take a look at what is 'same type'.

I am only interested in #2.

   Ta is declared to equal Tb in a type declaration of the form Ta = Tb

In this case, my interpretation as: a = b; c = b; then a = c.  This may not
be entirely true, but it makes sense.

Now, let's go to the crux of the matter, and why they are assignement
compatible.

Assignment compatibility states:

An expression e of type Te is assignment compatible witha variable v of
type Tv is one of the following conditions holds (In C-speak, e is an
rvalue, and v is an lvalue)

1) Te and Tv are the same type. [I think they are]
4) Te and Tv are pointer types and Te iss an extension of Tv.

I think #4 shows WHY they are allowed.  The pointer types are compatible.

Taylor "Couch Potato" Hutt
The opinions expressed herein are the property of B. Stroustrup. Maybe.

: We will have to wait for the ETH people to give an official answer,
 Agreed. It is too bad that there is no one on duty on the weekends
to handle crisis situations -:)

: First of all, let us take a look at what is 'same type'.
: I am only interested in #2.
:    Ta is declared to equal Tb in a type declaration of the form Ta = Tb
: In this case, my interpretation as: a = b; c = b; then a = c.  This may not
: be entirely true, but it makes sense.

No. This is making things up.

: Assignment compatibility states:

: An expression e of type Te is assignment compatible witha variable v of
: type Tv is one of the following conditions holds (In C-speak, e is an
: rvalue, and v is an lvalue)

: 1) Te and Tv are the same type. [I think they are]
     ** I don't think they are **
: 4) Te and Tv are pointer types and Te iss an extension of Tv.

: I think #4 shows WHY they are allowed.  The pointer types are compatible.

I agree that #4 shows WHY they are allowed. Te is an extension of Tv.
see Type extension rules.

If Pa = POINTER TO Ta and Pb = POINTER TO Tb, Pb is an extension of Pa
( Pa is a base type of Pb ) if Tb is an extension of Ta.
Without reading the rules I would have said that Tb is not an extension
of Ta, but that it is the same type as Ta. This is not the case :

Tb is an extension of Ta ( Ta is a base type of Tb ) if
1. Ta and Tb are the same types,

---------------------------------
BTW, another rule could work for some (broken) compilers.
see Assignment compatible rule 5.
Tv is a pointer or a procedure type and e is NIL.

If the compiler sets pointers to NIL, and applies data
flow before type-rules then m := f; becomes m := NIL;
--------------------------------

Whitney

 -> >
 -> >: MODULE test;
 -> >: TYPE
 -> >:   int = RECORD i : INTEGER END;
 -> >:   meters = POINTER TO int;
 -> >:   feet = POINTER TO int;
 -> >: VAR
 -> >:   m : meters;
 -> >:   f : feet;
 -> >: BEGIN
 -> >:   m := f;
 -> >: END test.

 -> First of all, let us take a look at what is 'same type'.
 ->
 -> I am only interested in #2.
 ->
 ->    Ta is declared to equal Tb in a type declaration of the form Ta = Tb
 ->
 -> In this case, my interpretation as: a = b; c = b; then a = c.  This may not
 -> be entirely true, but it makes sense.

No: "same type" as defined is not transitive. This is the first hole
in the definiton of type compatibilty.

But even if it were, same type applies to variables only.
Instantiating #2 for the case above I get:

  Two variables m and f with types meters and feet are of the same type
  if

  2. meters is declared to equal feet in a type declaration of the
  form meters=feet.

which is clearly false.

 -> Now, let's go to the crux of the matter, and why they are assignement
 -> compatible.
 ->
 -> Assignment compatibility states:
 ->
 -> An expression e of type Te is assignment compatible witha variable v of
 -> type Tv is one of the following conditions holds (In C-speak, e is an
 -> rvalue, and v is an lvalue)
 ->
 -> 1) Te and Tv are the same type. [I think they are]

No way.

 -> 4) Te and Tv are pointer types and Te iss an extension of Tv.

 -> I think #4 shows WHY they are allowed.  The pointer types are compatible.

That's it! I find the reasoning involved here pretty twisted, though.
Also, formally, there is a problem. The definition of Type Extension
uses the concept of "same type" for type names, whereas "same type' is
only defined for variables.

The attempt to give a precise definition of type
compatibility/equivalence should be applauded. The way it has been
defined, however, is full of exceptions and holes (for another
example, try to answer the question whether the relation "same type"
is symmetric).

One last thing: The reason this came up is because I tried to verify
that Pascal, Modula-2, and Oberon implement so-called declaration
equivalence of types (the occurrence of a type constructor defines a new
type). It turns out that Pascal and Modula-2 do (the above
program--mutatis mutandis--does not get past the type checker in all
six or so implementations that I tried), Oberon is supposed to, but
doesn't.

Edgar
--

Purdue University                      
Department of Computer Sciences         +1 (317) 494-6028 (voice)
West Lafayette, IN 47907-1398           +1 (317) 494-0739  (fax)

: First of all, let us take a look at what is 'same type'.
:    Ta is declared to equal Tb in a type declaration of the form Ta = Tb
: In this case, my interpretation as: a = b; c = b; then a = c.  This may not
: be entirely true, but it makes sense.

: An expression e of type Te is assignment compatible witha variable v of
: type Tv is one of the following conditions holds (In C-speak, e is an
: rvalue, and v is an lvalue)

Comparing C and Oberon is similar to comparing electrical
appliances such dish-washers and clothes-dryers.

Putting dishes into a clothes-dryer gives decorative sand.

Whitney

At any rate, due to this idea, I have just taken to skipping the washing
phase and tossing my dishes in the clothes-dryer.  As soon as they are
destroyed, there is no reason to wash them.  (Anyway, the abrasive sand
would clean them anyway...)

Taylor "Bon Ami" Hutt
I've taken a ride in a clothes dryer (MANY years ago).  Have you?