[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

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/3b7bddf5/attachment.html>