<div dir="ltr"><div dir="auto">I have found and old email where I asked Prof. Wirth the following:</div><div dir="auto"><br><div dir="auto">"I would like to know the reasoning behind the departure from array name </div><div dir="auto">equivalence in favour of array structural equivalence. </div><div dir="auto">i.e these two types are equivalent in Oberon-07 but not in Oberon-90</div><div dir="auto"><br></div><div dir="auto">TYPE A = ARRAY 3 OF INTEGER; </div><div dir="auto"> B = ARRAY 3 OF INTEGER; </div><div dir="auto"> </div><div dir="auto">Could you explain why you decided to change the language in this regard?"</div><div dir="auto"><br></div><div dir="auto">He replied saying that he does not remember the the exact circumstances, as the change was several years ago. <br></div><div dir="auto">He continued that the most obvious reason is that one needs less often to declare named types.</div><div dir="auto"><br></div><div>So I agree with Артур Ефимов, probably Wirth will update the language report soon.<br></div><div dir="auto"><br></div><div dir="auto">The changes I made in ORP.Mod regarding arrays are to enable the assignment "i := j;" below<br></div><div dir="auto"><br></div><div dir="auto">MODULE Arrays2;<br> TYPE T = ARRAY 3, 2 OF INTEGER;<br> <br> VAR<br> a: ARRAY 4 OF T;<br> b: ARRAY 4 OF T;<br> i: ARRAY 4, 3, 2 OF INTEGER;<br> j: ARRAY 4, 3, 2 OF INTEGER;<br> <br>BEGIN<br> a := b; (* this works *)<br> i := j; (* this should work, but illegal assignment in Wirth's Oberon *)<br>END Arrays2.</div><div dir="auto"><br></div><div>With the current ORP.Mod on Wirth's website, structural equivalence of arrays is half baked as it stops at the first array dimension.</div><div>In my fix I use the following procedure, that does a full structural check.<br></div><br> (* Type Rule I.1, I.2, I.4 *)<br> PROCEDURE SameArrays(t0, t1: ORB.Type): BOOLEAN;<br> BEGIN<br> RETURN (t0 = t1)<br> OR (t0.form = ORB.Array) & (t1.form = ORB.Array) & (t0.len = t1.len) &<br> SameArrays(t0.base, t1.base)<br> END SameArrays;</div><div dir="auto"><br></div><div>Regards,</div><div>Luca<br></div><div dir="auto"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 6, 2017 06:57, "August Karlstrom" <<a href="mailto:fusionfile@gmail.com" target="_blank">fusionfile@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2017-10-06 12:19, Andreas Pirklbauer wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
every procedure used as an actual parameter would have to be given an<br>
explicit name, ><br>
</blockquote>
I'm not sure what you mean here. Can you clarify?<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Personally I’m indifferent. I can live with the current status quo for<br>
arrays (where assignments of different ARRAY types are only allowed in<br>
the case of open arrays). But I would also accept a relaxation of the<br>
type equivalence rule in that case (knowing how easy it is to implement).<br>
</blockquote>
I agree with this. I primarily just want to know which features I can rely on.<br>
<br>
<br>
-- August<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer" target="_blank">https://lists.inf.ethz.ch/mail<wbr>man/listinfo/oberon</a><br>
</blockquote></div></div>
</div>