[Oberon] Clarifying type compatibility in Oberon-07

[Luca Boasso]

It is interesting to discover why the Go programming language introduced
type aliases to the language with the recent 1.9 release.
That feature was absent from day 1 to avoid the same problems Andreas was
referring to, but later they realized it is useful.
See  https://talks.golang.org/2016/refactor.article for more information.
The design document is here: https://golang.org/design/18130-type-alias

Note that the Go type system has a mix of name equivalence and structural
equivalence. If a type has a name, name equivalence is used otherwise
structural equivalence it used between anonymous types.
See the specification for the details:
https://golang.org/ref/spec#Type_identity

Cheers,
Luca Boasso

On Tue, Oct 10, 2017 at 8:43 PM, Diego Sardina <dsar at eml.cc> wrote:

> 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
>
>
> --
> 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/20171010/dd18bbf6/attachment.html>