<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">See the 2 inline comments below:</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">></span><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">> * </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">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 ; </span></font></div><div class=""><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> * p := r; (*ok -> structural equivalence suffices*)
</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> Acc 9.1 only allowed for open array. So, I see this as compiler bug. A hint why</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> it is a compiler bug: If the structural equivalence was included in SAME, exception</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> 4 mentioned in 9.1 would not be needed. So, it is in my view wrong to include</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> structural equivalence in SAME.</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">I just stated that </span></font><span style="font-family: monospace;" class="">structural equivalence for arrays *is* currently </span><span style="font-family: monospace;" class="">implemented (see</span></div><div class=""><span style="font-family: monospace;" class="">ORP.CompTypes) </span><span style="font-family: monospace;" class="">and also that the current language report does *not* </span><span style="font-family: monospace;" class="">actually make it</span></div><div class=""><span style="font-family: monospace;" class="">clear </span><font face="monospace" class="">whether it *should* be in the language or not. Whether it *should* be “in”</font></div><div class=""><font face="monospace" class="">or “out” </font><span style="font-family: monospace;" class="">is a separate question. There are of course the two options:</span></div><div class=""><font face="monospace" class=""> 1. It is viewed as a compiler bug -> then one should simply remove it</font></div><div class=""><font face="monospace" class=""> 2. It is not viewer as a bug -> then one should remove exception 4 in 9.1.</font></div><div class=""><font face="monospace" class="">But either way, the language report should be updated such that there is no ambiguity.</font></div><div class=""><font face="monospace" class=""><br class=""></font></div><div class=""><font face="monospace" class=""><br class=""></font></div><div class=""><font face="monospace" class="">> * e := g; (*ok -> structural equivalence suffices*)</font></div><div class=""><font face="monospace" class="">></font></div><div class=""><font face="monospace" class="">> My interpretation of section 6.5: only allowed it for (const) P.</font></div><div class=""><font face="monospace" class="">> A “g” is a variable, I would not allow. </font></div><div class=""><font face="monospace" class=""><br class=""></font></div><div class=""><font face="monospace" class="">Same response here. At the very least, the language report needs to be made</font></div><div class=""><font face="monospace" class="">clearer. </font><span style="font-family: monospace;" class="">Currently it states: "If a procedure </span><span style="font-family: monospace;" class="">P is assigned to a procedure</span></div><div class=""><span style="font-family: monospace;" class="">variable of type T”. </span><font face="monospace" class="">To most people (including you) the word “a procedure P”</font></div><div class=""><font face="monospace" class="">means "procedures declared the usual way” </font><span style="font-family: monospace;" class="">but excludes procedure *variables*.</span></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><font face="monospace" class="">=></font></div><div class=""><font face="monospace" class=""><br class=""></font></div><div class=""><div class=""><span style="font-family: monospace;" class="">I think we really have exhausted this topic and are scraping the bottom. All</span></div><div class=""><font face="monospace" class="">arguments are on the table, with different points of views for the pros and cons.</font></div><div class=""><font face="monospace" class=""><br class=""></font></div><div class=""><font face="monospace" class="">But we all (seem to) agree that the language report needs revision in that</font></div><div class=""><span style="font-family: monospace;" class="">it should a) leave no ambiguity and b) be in line with the implementation.</span></div></div><div class=""><br class=""></div><div class=""><font face="monospace" class="">-AP<br class=""></font><div class=""><br class=""></div></div></div></div></body></html>