[Oberon] Type compatibility rules for Pointers

[Chris Burrows]

I thought so. I have found the other set of rules that I was thinking of. They were proposed by Luca Boasso:

 

https://github.com/lboasso/OberonRISC5/blob/master/TypeRules.md

 

There are differences between Luca’s and Karl’s if anybody is interested in investigating further.

 

Regards,

Chris Burrows

CFB Software

https://www.astrobe.com/RISC5

 

 

From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Chris Burrows
Sent: Tuesday, 16 June 2020 3:48 PM
To: ETH Oberon and related systems
Subject: Re: [Oberon] Type compatibility rules for Pointers

 

Jörg

 

I seem to recall being involved, with others, in an email review of this list. My recollection was that is was somebody else rather than Karl – there may be another similar list in existence. As far as I know it is solely an unofficial interpretation of the report. As he says in the introduction:

……

 

From: Joerg [mailto:joerg.straube at iaeth.ch] 
Sent: Tuesday, 16 June 2020 3:00 PM
To: chris at cfbsoftware.com <mailto:chris at cfbsoftware.com> ; ETH Oberon and related systems
Subject: Re: [Oberon] Type compatibility rules for Pointers

 

Chris

 

Where does Karl Landström have the missing info from?

a) own interpretation of the report

b) compiler code

If a) who says this list is correct?

If b) the special case of ARRAY OF BYTE is missing.

 

br

Jörg

 

Am 16.06.2020 um 03:40 schrieb Chris Burrows <chris at cfbsoftware.com <mailto:chris at cfbsoftware.com> >:



> -----Original Message-----

> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of chris

> Sent: Tuesday, 16 June 2020 5:37 AM

> To: ETH Oberon and related systems

> Subject: Re: [Oberon] Type compatibility rules for Pointers

> 

> On Mon, 15 Jun 2020 21:42:39 +0200, Michael Schierl wrote:

> > Are you equally confused when you replace POINTER TO R by ARRAY 42 OF

> > BYTE or even by INTEGER?

> >

> > i.e.

> >

> > TYPE I1 = INTEGER; I2 = INTEGER;

> >   A1 = ARRAY 42 OF BYTE;

> >   A2 = ARRAY 42 OF BYTE;

> 

> Yes I am. In my understanding this breaks the longstanding tradition since

> the Modula days, that type compatibility is declared by name and not

> inferred by structure (Only exception are procedure types for obvious

> reasons and type extension).

> 

> > As I understand it, of all custom types only record types have identity.

> > All other types are just aliases of what is on the other side of the

> > equals sign. So it should not matter if you replace every occurrence

> > of

> > I1 by INTEGER or A1 by ARRAY 42 OF BYTE

> 

> The declaration

>      I1 = INTEGER;

> declares an alias and no new type. ARRAY 42 OF BYTE is a new type.

> 

> The Oberon-2 report for example gives the first formal definition of "same

> type" I know of and it clearly states in 1. that same types means same type

> identifier.

> 

> "Same types"

>      Two variables a and b with types Ta and Tb are of the same type if

>      1. Ta and Tb are both denoted by the same type identifier, or

>      2. Ta is declared to equal Tb in a type declaration of the form Ta

> =

>              Tb, or

>      3. a and b appear in the same identifier list in a variable, record

>              field, or formal parameter declaration and are not open

> arrays.

> 

> > I am not sure where I have this from (I can see that it is not

> > actually defined in the Oberon 07 Report), perhaps this is just from

> > experience from other programming languages.

> 

> Looks you are right about Oberon-07. The Oberon-07 report is very vague

> about this.

> 

 

There has been much debate about this in the past. Not all of the rules are explicitly spelt out in the Language Report. In the introduction to the Language Report Wirth says:

 

“… What remains unsaid is mostly left so intentionally, either because it is derivable from stated rules of the language…”

 

However, that does require the reader to exercise some mental gymnastics in cases like these. If you prefer a more explicit version, I recommend this one. I believe it to be correct but would be interested if anybody spots any flaws:

 

https://miasap.se/obnc/type-compatibility.html

 

Regards,

Chris Burrows

CFB Software

https://www.astrobe.com

 

 

--
Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch>  mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200616/b6f20e0f/attachment-0001.html>