[Oberon] Clarifying type compatibility in Oberon-07

[Claudio Nieder]

Hi,

To make Jörg’s point even clearer, let me say that one of the functions of a type system is to safeguard from programming errors. Reason I declare something of type A and something of type B is to make clear that a and b are not compatible and thus whenever I use the two in the same computation, the compiler will tell me, that I am doing something stupid. If then A and B are structurally equivalent and therefor the compiler accepts I mix a and b in a computation and the compiler does not give an error then I loose the type safety.

Said that I understand the discussion that is happening now, because there are two sides of the medal. The one side is the above mentioned. The other one is, that there are some generic concepts that apply to all kind of structural equivalent things. Thus sometimes you prefer one behaviour sometimes the other.

Some programming languages try to offer both by having structural equivalence with an added way to declare a type as something distinct which is based on that structure, some mechanisms that would even allow you to declare Apples=new Integer, Oranges=new Integer, causing then apples+oranges be flagged as an error yet providing all integer operations so you can do appleBag1+appleBag2, The downside is of course, that such a language is more complex than Oberon.

I don’t really know what the “best” solution is. I tend to prefer type safety over convenience, because it helps me in writing programs with less bugs.

claudio

> On 6. Oct. 2017, at 13:20, Jörg <joerg.straube at iaeth.ch> wrote:
> 
> 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 <mailto:oberon-bounces at lists.inf.ethz.ch>> im Auftrag von Andreas Pirklbauer <andreas_pirklbauer at yahoo.com <mailto:andreas_pirklbauer at yahoo.com>>
> Antworten an: ETH Oberon and related systems <oberon at lists.inf.ethz.ch <mailto: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 <mailto: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 <mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon <https://lists.inf.ethz.ch/mailman/listinfo/oberon>--
> Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon <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/fd5cd94d/attachment.html>