[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

>
> Personally, I’m not indifferent ☺
>
> I know that it can be done, but the question is WHY.
> Only because something can be done is a poor reason to do it.
>
>
> If you put  a := b in your code, you do that as you know or
> assume a certain relationship between those two variables
> (they e.g. represent instances of the same or comparable
> thing). If this hold true, I don’t understand why you
> have to write two totally independent type declarations
> that (by accident) match structurally.
>
> br
>
> Jörg
>

Jörg, you have a valid point - no question! I value such input. As
I said myself earlier “I just don’t have a good enough reason yet”.

But I do want to continue exploring the question a little bit, now
that the topic has come up for the N-th time in M decades. Perhaps
this time around, someone comes up with a new insight or a “good
enough” reason for changing the language.

If I understand you correctly, your position can also be viewed
as: “If as a language designer one does have a chance or option
to promote ‘good’ programming style (whatever that means), one
should by all means use it”. In the particular case of array
type equivalence discussed in this forum, it effectively amounts
to forcing programmers to write one type declaration instead of two;
which I too view as good programming practice, which in addition
increases code readability in my opinion.

Perhaps yet another way to look at your position is this: Once I do
allow structural equivalence for arrays, I can never go back in the
future without breaking someone’s legacy code. So, in the absence
of a really compelling reason to actually *allow* structural
equivalence for arrays, one should “play safe” and disallow it.
Perhaps that is what the Pascal/Modula/Oberon compiler writers
felt all those years..

PS: I’m now 60/40 - does that make you feel better? ;-)

-AP



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171006/873d47a9/attachment.html>