[Oberon] Clarifying type compatibility in Oberon-07
fusionfile at gmail.com
Fri Oct 6 10:38:07 CEST 2017
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
Yes, if you read this thread you will find that this is what I have
> 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
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?
More information about the Oberon