[Oberon] Clarifying type compatibility in Oberon-07

[Jörg]

VAR

  nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;

  nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;

 

nbrOfBirthPerMonth := nbrOfAccidentsPerMonth (* these match structurally but makes not much sense, should be forbidden *)

 

If you want to write a generic module handling monthly statistics, you have open ARRAYs and the exceptions for assignments of actual to formal.

 

PROCEDURE StoreYear (a: ARRAY OF INTEGER);    (* … *)

 

StoreYear (nbrOfBirthsPerMonth); (* structural match *)

StoreYear (nbrOfAccidentsPerMonth);

 

If you have a procedure like StoreBirths (); you should not use open ARRAYs, as then StoreBirths (nbrOfAccidentsPerMonth) would be possible…

 

br

Jörg

 

 

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Datum: Freitag, 6. Oktober 2017 um 13:17
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: [Oberon] Clarifying type compatibility in Oberon-07

 

> 

> 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






 

-- 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/20171006/921dcf09/attachment.html>