[Oberon] Clarifying type compatibility in Oberon-07

[Jörg]

Did somebody contact NW already?

Jörg

 

From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Andreas Pirklbauer
Sent: Thursday, October 12, 2017 3:16 PM
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: [Oberon] Clarifying type compatibility in Oberon-07

 

See the 2 inline comments below:





> 

> * MODULE M; (*test of the implementation of Oberon-07 as of 12.10.17*) > * VAR > * p, q: ARRAY 10 OF INTEGER; > * r, s: ARRAY 10 OF INTEGER; > * e, f: PROCEDURE (i, j: INTEGER); > * g, h: PROCEDURE (i, j: INTEGER); > * a, b: RECORD i, j: INTEGER END ; > * c, d: RECORD i, j: INTEGER END ; 





> * p := r; (*ok -> structural equivalence suffices*) 

> 

> Acc 9.1 only allowed for open array. So, I see this as compiler bug. A hint why

> it is a compiler bug: If the structural equivalence was included in SAME, exception

> 4 mentioned in 9.1 would not be needed. So, it is in my view wrong to include

> structural equivalence in SAME.





I just stated that structural equivalence for arrays *is* currently implemented (see

ORP.CompTypes) and also that the current language report does *not* actually make it

clear whether it *should* be in the language or not. Whether it *should* be “in”

or “out” is a separate question. There are of course the two options:

  1. It is viewed as a compiler bug -> then one should simply remove it

  2. It is not viewer as a bug -> then one should remove exception 4 in 9.1.

But either way, the language report should be updated such that there is no ambiguity.

 

 

> * e := g; (*ok -> structural equivalence suffices*)

> 

> My interpretation of section 6.5: only allowed it for (const) P.

> A “g” is a variable, I would not allow. 

 

Same response here. At the very least, the language report needs to be made

clearer. Currently it states: "If a procedure P is assigned to a procedure

variable of type T”. To most people (including you) the word “a procedure P”

means "procedures declared the usual way” but excludes procedure *variables*.

 

 

=>

 

I think we really have exhausted this topic and are scraping the bottom. All

arguments are on the table, with different points of views for the pros and cons.

 

But we all (seem to) agree that the language report needs revision in that

it should a) leave no ambiguity and b) be in line with the implementation.

 

-AP

 

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