<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>Dear all, <br><br></div>Last year I was exchanging emails with Prof. Wirth to discuss Oberon-07's type system.<br></div>That discussion lead to updates to the compiler (see Wirth's news.txt: 20160508, 20160501, 20160418 and 20160410).<br></div>Recently, I had similar private conversations with Andreas Pirklbauer.  <br><br></div>I would like to present here, to a wider audience, what I think Oberon-07 type rules should be, with a set of fixes to ORP.Mod to reflect these rules.</div><div>The type rules are adapted from the Appendix A of the Oberon-2 report, and are an attempt to marry Oberon-07 new rules with the proven ones of Oberon-2.</div><div>The fixes to ORP.Mod are as minimal as possible and are aimed to weed out inconsistencies of the current implementation.</div><div></div><div>I have tried these changes for the last half year with no issues, I will later share a set of tests that I made to verify the implementation.<br></div><div><br></div><div>I think that discussing the rules in plain English is not enough, because different people have different interpretations. For this reason I ask you to look at the changes in the code.</div><div> I have added comments like "(* Type Rule X *)" above the code that handles the implementation of Rule X from the TypeRules.txt file.</div><br></div>I have created a new GitHub repository to track the changes and share them. Please fell free to contribute, the link is: <a href="https://github.com/lboasso/OberonRISC5" target="_blank">https://github.com/lboasso/<wbr>OberonRISC5</a><br><br></div>In particular here is the TypeRules.txt file: <a href="https://raw.githubusercontent.com/lboasso/OberonRISC5/master/TypeRules.txt" target="_blank">https://raw.githubusercontent.<wbr>com/lboasso/OberonRISC5/<wbr>master/TypeRules.txt</a><br></div>And here is the diff of the changes I made to ORP.Mod: <a href="https://github.com/lboasso/OberonRISC5/commit/3f5b5c3d5fbf632e82902e9fbbaf93ef8285e577#diff-ec269f2dcbbad1d06c87c72169d0fcf2" target="_blank">https://github.com/lboasso/<wbr>OberonRISC5/commit/<wbr>3f5b5c3d5fbf632e82902e9fbbaf93<wbr>ef8285e577#diff-<wbr>ec269f2dcbbad1d06c87c72169d0fc<wbr>f2</a><br><br></div>I hope this would help the current discussion. My hope is to reach a consensus, that could be eventually blessed by Prof. Wirth.<br></div>I do not claim to have found the final rules, but this could be a step in the right direction with your feedback.<br><br></div>Regards, <br></div>Luca Boasso<br><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 5, 2017 at 10:48 AM, August Karlstrom <span dir="ltr"><<a href="mailto:fusionfile@gmail.com" target="_blank">fusionfile@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2017-10-05 19:05, Jörg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As with the pointer assignment discussed earlier, the structural equivalence for procedures variables is rather a by-product.<br>
</blockquote>
<br></span>
But sometimes the by-product is something you don't want. Name equivalence has its semantical advantages when you want to prevent a mix of apples and oranges.<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>