[Oberon] Clarifying type compatibility in Oberon-07

[Luca Boasso]

Dear all,

Last year I was exchanging emails with Prof. Wirth to discuss Oberon-07's
type system.
That discussion lead to updates to the compiler (see Wirth's news.txt:
20160508, 20160501, 20160418 and 20160410).
Recently, I had similar private conversations with Andreas Pirklbauer.

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.
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.
The fixes to ORP.Mod are as minimal as possible and are aimed to weed out
inconsistencies of the current implementation.
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.

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.
I have added comments like "(* Type Rule X *)" above the code that handles
the implementation of Rule X from the TypeRules.txt file.

I have created a new GitHub repository to track the changes and share them.
Please fell free to contribute, the link is: https://github.com/lboasso/
OberonRISC5

In particular here is the TypeRules.txt file: https://raw.githubusercontent.
com/lboasso/OberonRISC5/master/TypeRules.txt
And here is the diff of the changes I made to ORP.Mod:
https://github.com/lboasso/OberonRISC5/commit/3f5b5c3d5fbf632e82902e9fbbaf93
ef8285e577#diff-ec269f2dcbbad1d06c87c72169d0fcf2

I hope this would help the current discussion. My hope is to reach a
consensus, that could be eventually blessed by Prof. Wirth.
I do not claim to have found the final rules, but this could be a step in
the right direction with your feedback.

Regards,
Luca Boasso


On Thu, Oct 5, 2017 at 10:48 AM, August Karlstrom <fusionfile at gmail.com>
wrote:

> On 2017-10-05 19:05, Jörg wrote:
>
>> As with the pointer assignment discussed earlier, the structural
>> equivalence for procedures variables is rather a by-product.
>>
>
> 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.
>
>
>
> -- August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171005/d4cb49dd/attachment.html>