<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=""><span style="font-family: monospace; white-space: pre-wrap;" class="">> On </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">Fri Oct 6 10:38:07 CEST 2017 August Karlstrom wrote</span></font><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="">> His reply was: "Yes, I consider this type compatibility as an </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">addition to</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">> the language definition. I think it makes sense, and it is easy to implement."</span></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="">> I realize now that it is not really clear if he means that the structural</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> equivalence is a "non-standard" feature, or if the language definition has</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> changed, implying that every Oberon-07 compiler should work this way.</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> What do you think?</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span></font></div><div class=""><br class=""></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">This reply can be read either way - perhaps you can check back on this,</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">just </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">to be sure. But </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">the last </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">part </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">("makes sense, easy to implement”)</span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">seems to signal </span><span style="white-space: pre-wrap; font-family: monospace;" class="">that </span><span style="white-space: pre-wrap; font-family: monospace;" class="">there </span><span style="white-space: pre-wrap; font-family: monospace;" class="">is (now) </span><span style="white-space: pre-wrap; font-family: monospace;" class="">at </span><span style="white-space: pre-wrap; font-family: monospace;" class="">least </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">openness to the idea of</span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">changing the language itself.</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">It’s perhaps worth inserting a historical comment at this point:</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="">There is </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">of course </span><span style="white-space: pre-wrap; font-family: monospace;" class="">a very long discussion history on this </span><span style="white-space: pre-wrap; font-family: monospace;" class="">topic. Each</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">time a </span><span style="white-space: pre-wrap; font-family: monospace;" class="">new </span><span style="white-space: pre-wrap; font-family: monospace;" class="">language (</span><span style="white-space: pre-wrap; font-family: monospace;" class="">or at least a new compiler for an </span><span style="white-space: pre-wrap; font-family: monospace;" class="">existing language)</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">has been </span><span style="white-space: pre-wrap; font-family: monospace;" class="">developed </span><span style="white-space: pre-wrap; font-family: monospace;" class="">at ETH, </span><span style="white-space: pre-wrap; font-family: monospace;" class="">this </span><span style="white-space: pre-wrap; font-family: monospace;" class="">topic has </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">came up. </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">I remember having had</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">to prepare an </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">“informed </span><span style="white-space: pre-wrap; font-family: monospace;" class="">point </span><span style="white-space: pre-wrap; font-family: monospace;" class="">of view” (whatever </span><span style="white-space: pre-wrap; font-family: monospace;" class="">that meant, presumably</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">a </span><span style="white-space: pre-wrap; font-family: monospace;" class="">list </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">of pros and </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">cons</span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">) </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">for </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">one of NW’s classes back in </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">1988 for the</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">Oberon</span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""> </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">implementation on Ceres, </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">which had then just </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">come out</span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">. But</span></font><span style="white-space: pre-wrap; font-family: monospace;" class=""> even</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">before that, </span><span style="white-space: pre-wrap; font-family: monospace;" class="">this </span><span style="white-space: pre-wrap; font-family: monospace;" class="">topic was </span><span style="white-space: pre-wrap; font-family: monospace;" class="">periodically touched upon </span><span style="white-space: pre-wrap; font-family: monospace;" class="">by various people,</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">certainly </span><span style="font-family: monospace; white-space: pre-wrap;" class="">in the contexts </span><span style="font-family: monospace; white-space: pre-wrap;" class="">of the </span><span style="font-family: monospace; white-space: pre-wrap;" class="">Modula on Lilith (1982) </span><span style="font-family: monospace; white-space: pre-wrap;" class="">and </span><span style="font-family: monospace; white-space: pre-wrap;" class="">the Pascal</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">on PDP (1975) implementation projects that were all </span><span style="font-family: monospace; white-space: pre-wrap;" class="">carried out at ETH</span><span style="font-family: monospace; white-space: pre-wrap;" class="">.</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">But surprisingly, despite this long </span><span style="font-family: monospace; white-space: pre-wrap;" class="">discussion </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">history and all the “grey</span></font></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">brain matter" devoted to this important subject </span><span style="font-family: monospace; white-space: pre-wrap;" class="">over all these </span><span style="font-family: monospace; white-space: pre-wrap;" class="">years,</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">a "final word" has never been spoken. </span><span style="font-family: monospace; white-space: pre-wrap;" class="">Maybe an accident of </span><span style="font-family: monospace; white-space: pre-wrap;" class="">history.</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">Or perhaps people thought that it would somehow negatively </span><span style="font-family: monospace; white-space: pre-wrap;" class="">impact code</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">portability on different systems, </span><span style="font-family: monospace; white-space: pre-wrap;" class="">or be difficult to implement - which</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">it is not, </span><span style="font-family: monospace; white-space: pre-wrap;" class="">as we now know. Or perhaps people simply didn't agree..</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">I just checked the source code of all these implementations and </span><span style="white-space: pre-wrap; font-family: monospace;" class="">can say</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">this: Historically, most Pascal, Modula and Oberon </span><span style="font-family: monospace; white-space: pre-wrap;" class="">implementations </span><span style="font-family: monospace; white-space: pre-wrap;" class="">(at</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">least the ones </span><span style="font-family: monospace; white-space: pre-wrap;" class="">realized at ETH) generally assume *name compatibility*</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">as the basis </span><span style="font-family: monospace; white-space: pre-wrap;" class="">for establishing type consistency. In each of these cases,</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">there were/are only a </span><span style="font-family: monospace; white-space: pre-wrap;" class="">small, but </span><span style="font-family: monospace; white-space: pre-wrap;" class="">usually </span><span style="font-family: monospace; white-space: pre-wrap;" class="">well-documented exceptions to</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">this rule, for </span><span style="font-family: monospace; white-space: pre-wrap;" class="">example </span><span style="font-family: monospace; white-space: pre-wrap;" class="">open arrays, open array parameters and procedure</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">parameters, </span><span style="font-family: monospace; white-space: pre-wrap;" class="">where </span><span style="font-family: monospace; white-space: pre-wrap;" class="">structural </span><span style="font-family: monospace; white-space: pre-wrap;" class="">compatibility suffices. These were well</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">justified </span><span style="font-family: monospace; white-space: pre-wrap;" class="">exceptions to the rule (for example, otherwise every procedure</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">used as an actual </span><span style="font-family: monospace; white-space: pre-wrap;" class="">parameter would have to be given an explicit name,</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">which </span><span style="font-family: monospace; white-space: pre-wrap;" class="">was considered as too cumbersome - hence the exception).</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">If it’s true that there now is a chance to change the Oberon language</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">itself, </span></font><span style="font-family: monospace; white-space: pre-wrap;" class="">we’re down to the question, whether it “makes sense”or not.</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">That’s all there is to it. All arguments appear to be in the table.</span></font></div><div class=""><br class=""></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">Jörg has made a few points on this topic in an earlier post </span><span style="white-space: pre-wrap; font-family: monospace;" class="">("currently</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">a := b is not allowed for </span><span style="white-space: pre-wrap; font-family: monospace;" class="">VAR a: ARRAY 10 OF CHAR; b: ARRAY 10 CHAR, </span><span style="font-family: monospace; white-space: pre-wrap;" class="">because</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">there are several ways to allow this already eg VAR a, b: ARRAY 10 OF CHAR").</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">On the other hand, I have also been working with Luca’s implementation</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">of ORP </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">(which </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">fully implements structural equivalence for arrays) for some</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">time </span><span style="white-space: pre-wrap; font-family: monospace;" class="">now, I must say that I can’t </span><span style="white-space: pre-wrap; font-family: monospace;" class="">see any issues with that. It works!</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">(small addition: n</span><span style="white-space: pre-wrap; font-family: monospace;" class="">ot </span><span style="white-space: pre-wrap; font-family: monospace;" class="">so sure about portability when different compilers</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">are used, perhaps someone else can chip in here</span><span style="font-family: monospace; white-space: pre-wrap;" class="">).</span></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="">Personally I’m indifferent. I can live with the current status quo for</span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">arrays (where </span><span style="white-space: pre-wrap; font-family: monospace;" class="">assignments of different </span><span style="white-space: pre-wrap; font-family: monospace;" class="">ARRAY types are only allowed in</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">the case of </span><span style="font-family: monospace; white-space: pre-wrap;" class="">open arrays). But I would also accept </span><span style="font-family: monospace; white-space: pre-wrap;" class="">a relaxation of the</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">type equivalence rule in that case (knowing how easy it is to implement).</span></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="">Any additional thoughts?</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="">-AP</span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><br class=""></div></body></html>