[Oberon] Clarifying type compatibility in Oberon-07
Andreas Pirklbauer
andreas_pirklbauer at yahoo.com
Wed Oct 11 10:20:13 CEST 2017
> 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>
More information about the Oberon
mailing list