<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> On Wed Oct 11 05:43:23 CEST 2017 Diego Sardina wrote:</span></font><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> 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</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">>   equivalence, like in Pascal-family languages).
></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">> 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.</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">I once programmed a spreadsheet program using Ada on VAX, so I can relate</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">to your </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">comment on name equivalence. I programmed in Ada as in Oberon.</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">But back to Oberon: </span></font><span style="font-family: monospace; white-space: pre-wrap;" class="">I included the </span><span style="font-family: monospace; white-space: pre-wrap;" class="">second </span><span style="font-family: monospace; white-space: pre-wrap;" class="">variant (which </span><span style="font-family: monospace; white-space: pre-wrap;" class="">defines</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class="">two aliases </span><span style="font-family: monospace; white-space: pre-wrap;" class="">for the type INTEGER) only </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">to show that </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">this *additional*</span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">way of expressing </span><span style="font-family: monospace; white-space: pre-wrap;" class="">the assignment is *also* accepted by Oberon-07.</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">One could in fact reduce my argument even further to the following </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">question:</span></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">How is this code (“code A”):</span></font></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">  VAR</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">    nbrOfBirthsPerMonth: ARRAY 12 OF INTEGER;
    nbrOfAccidentsPerMonth: ARRAY 12 OF INTEGER;
<br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">  nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*these match structurally but makes not much sense, should be forbidden*)<br class=""></span></font></div><div class=""><span style="font-family: monospace; white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">CONCEPTUALLY different from the following code (“code B”):</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">
  VAR
    nbrOfBirthsPerMonth: INTEGER;
    nbrOfAccidentsPerMonth: INTEGER;

    nbrOfBirthsPerMonth := nbrOfAccidentsPerMonth; (*allowed, but *also* makes not much sense*)
<br class="">when in comes to name equivalence vs structural equivalence?</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">As an argument in favor of name equivalence, Jörg has stated earlier: “When a</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">programmer </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">writes a := b in his code, </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">then he typically </span><span style="white-space: pre-wrap; font-family: monospace;" class="">does that as he knows</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">or assumes </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">a "certain relationship” between </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">those two variables (they </span><span style="white-space: pre-wrap; font-family: monospace;" class="">e.g.</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">represent instances of the same or comparable “thing”).</span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">” </span></font></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">Often times, </span><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">this relationship </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">is expressed using a type relationship,</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">but not always as the above example with INTEGER shows! </span></font><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">In other words,</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">a programmer </span></font><span style="white-space: pre-wrap; font-family: monospace;" class="">can *always” create assignments that “make no </span><span style="white-space: pre-wrap; font-family: monospace;" class="">sense”.</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">So why we should we </span><span style="white-space: pre-wrap; font-family: monospace;" class="">impose a rule for arrays or records, when it cannot</span></div><div class=""><span style="white-space: pre-wrap; font-family: monospace;" class="">be imposed with </span><span style="white-space: pre-wrap; font-family: monospace;" class="">basic types such as INTEGER?</span></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">Purist vs. pragmatist view clashing here :-)</span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></font></div><div class=""><font face="monospace" class=""><span style="white-space: pre-wrap;" class="">-AP</span><br class="Apple-interchange-newline"><br class=""></font></div><div class=""><br class=""></div></body></html>