[Oberon] Clarifying type compatibility in Oberon-07

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Wed Oct 11 10:27:35 CEST 2017

> On Wed Oct 11 07:59:12 CEST 2017 Jürg Straube wrote:
> 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.
> Most prominent example of type aliasing with basic types is TYPE LONGINT = INTEGER;
> Jörg

I should have left the variant *with* the type aliases for INTEGER out. Because the
issue we are discussing here even exists *without* aliases, as the (re-posted) question
below shows. Type aliases only add an additional complication or consideration.


How is this code (“code A”):

    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”):

    nbrOfBirthsPerMonth: INTEGER;
    nbrOfAccidentsPerMonth: INTEGER;

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

when in comes to name equivalence vs structural equivalence?"

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

More information about the Oberon mailing list