[Oberon] Clarifying type compatibility in Oberon-07

[August Karlstrom]

On 2017-10-06 05:52, Luca Boasso wrote:
> Dear all,
> 
> Last year I was exchanging emails with Prof. Wirth to discuss 
> Oberon-07's type system.

NW tends to come up with new ideas quite often so his opinion today may 
be different from last year.

> That discussion lead to updates to the compiler (see Wirth's news.txt: 
> 20160508, 20160501, 20160418 and 20160410).

If I remember correctly this was when type aliases were reintroduced 
(identdef = typeName), something he mentioned he don't really like but 
added because people requested it.

> 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.

Yes, if you read this thread you will find that this is what I have 
already suggested.

> 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, 

At least for me, appendix A in the Oberon-2 report is sufficiently clear 
for describing Oberon-2's type rules.

> 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.
Nice effort. I have been in contact with NW this week and I asked him 
about the structural equivalence used in assignment of [non-open] array 
and procedure variables. Here is my question:

"I ideally want to write long-lived programs that can be compiled with 
different implementations of Oberon07. What I wonder is basically if 
this structural equivalence is to be seen as a language extension of 
your compiler?"

His reply was:

"Yes, I consider this type compatibility as an addition tothe language 
definition. I think it makes sense, and it is easy to implement."

I realize now that it is not really clear if he means that the 
structural equivalence is a "non-standard" feature, or if the language 
definition has changed, implying that every Oberon-07 compiler should 
work this way. What do you think?


-- August