[Oberon] Clarifying type compatibility in Oberon-07

[Diego Sardina]

On Wed, Oct 11, 2017, at 12:48 AM, Andreas Pirklbauer wrote:
> > ---------------------------------------------------
> > On Fri Oct 6 12:40:42 CEST 2017 Jörg Straube:
> > 
> > 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.
> >
> > ---------------------------------------------------
> > On Fri Oct 6 13:20:09 CEST 2017 Jörg Straube 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*)> >
> > ---------------------------------------------------
> 
> Jörg,
> as I said earlier, I agree that you kind of have a point here.
> HOWEVER, how is your example conceptually different from:> 
> VAR
> nbrOfBirthsPerMonth: INTEGER; nbrOfAccidentsPerMonth: INTEGER;
> nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed, but *also*
> makes not much sense*)> 
> or from this:
> 
> TYPE Births = INTEGER;
> Accidents = INTEGER;
> 
> VAR
> nbrOfBirthsPerMonth: Births; nbrOfAccidentsPerMonth: Accidents;
> nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed*)
> 
> both of which are allowed in Oberon (the second variant is allowed,
> because in Oberon type aliases are considered as the *same type*), but
> “make no sense” according to your logic?> 
> In other words: If we *really* were to take a purist point of view
> (which I am NOT advocating!!), we might as well have the same
> discussion for the basic types such as INTEGER, i.e. without even
> referring to structured types (arrays or records).> 
> Just saying...
> -AP


These are different considerations.

In the right part (after "=") of a type definition, ARRAY, RECORD,
POINTER TO and PROCEDURE are to be considered *type constructor* for
defining new types, while in the case of an identifier denoting an
already existing named type (aliasing), you may choose between:
- an alias introduces a distinct type (strict name equivalence, like
  in Ada), or- an alias introduces an equivalent type (loose name equivalence, like
  in Pascal-family languages).
As an ex Ada programmer, I  liked the strict name equivalence principle.
But I consider it useless now, because in every case I always evolved a
type from aliasing a basic type to a record type, introducing more
properties to it.
Indeed I liked the idea of removing type aliasing in Oberon-07, but it
was reintroduced in the previous year. Wirth justified it saying that
sometimes it's useful to introduce a short synonym for a lengthy,
imported type name.

--
Diego Sardina

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