[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

> On Wed Oct 11 05:43:23 CEST 2017 Diego Sardina wrote:
>
> 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.
>

I once programmed a spreadsheet program using Ada on VAX, so I can relate
to your comment on name equivalence. I programmed in Ada as in Oberon.
But back to Oberon: I included the second variant (which defines
two aliases for the type INTEGER) only to show that this *additional*
way of expressing the assignment is *also* accepted by Oberon-07.

One could in fact reduce my argument even further to the following question:

How is this code (“code A”):

  VAR
    nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;
    nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;

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

CONCEPTUALLY different from the following code (“code B”):

  VAR
    nbrOfBirthsPerMonth: INTEGER;
    nbrOfAccidentsPerMonth: INTEGER;

    nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed, but *also* makes not much sense*)

when in comes to name equivalence vs structural equivalence?

As an argument in favor of name equivalence, Jörg has stated earlier: “When a
programmer writes a := b in his code, then he typically does that as he knows
or assumes a "certain relationship” between those two variables (they e.g.
represent instances of the same or comparable “thing”).” 

Often times, this relationship is expressed using a type relationship,
but not always as the above example with INTEGER shows! In other words,
a programmer can *always” create assignments that “make no sense”.

So why we should we impose a rule for arrays or records, when it cannot
be imposed with basic types such as INTEGER?

Purist vs. pragmatist view clashing here :-)

-AP


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