[Oberon] Clarifying type compatibility in Oberon-07

[Andreas Pirklbauer]

> On Fri Oct 6 10:38:07 CEST 2017 August Karlstrom wrote
>
> His reply was: "Yes, I consider this type compatibility as an addition to
> the language  definition. I think it makes sense, and it is easy to implement."
>
> I realize now that it is not really clear if he means that the structural
> equivalence is a "non-standard" feature, or if the language  definition has
> changed, implying that every Oberon-07 compiler should  work this way.
> What do you think?
>

This reply can be read either way - perhaps you can check back on this,
just to be sure. But the last part ("makes sense, easy to implement”)
seems to signal that there is (now) at least openness to the idea of
changing the language itself.

It’s perhaps worth inserting a historical comment at this point:

There is of course a very long discussion history on this topic. Each
time a new language (or at least a new compiler for an existing language)
has been developed at ETH, this topic has came up. I remember having had
to prepare an “informed point of view” (whatever that meant, presumably
a list of pros and cons) for one of NW’s classes back in 1988 for the
Oberon implementation on Ceres, which had then just come out. But even
before that, this topic was periodically touched upon by various people,
certainly in the contexts of the Modula on Lilith (1982) and the Pascal
on PDP (1975) implementation projects that were all carried out at ETH.
But surprisingly, despite this long discussion history and all the “grey
brain matter" devoted to this important subject over all these years,
a "final word" has never been spoken. Maybe an accident of history.
Or perhaps people thought that it would somehow negatively impact code
portability on different systems, or be difficult to implement - which
it is not, as we now know. Or perhaps people simply didn't agree..

I just checked the source code of all these implementations and can say
this: Historically, most Pascal, Modula and Oberon implementations (at
least the ones realized at ETH) generally assume *name compatibility*
as the basis for establishing type consistency. In each of these cases,
there were/are only a small, but usually well-documented exceptions to
this rule, for example open arrays, open array parameters and procedure
parameters, where structural compatibility suffices. These were well
justified exceptions to the rule (for example, otherwise every procedure
used as an actual parameter would have to be given an explicit name,
which was considered as too cumbersome - hence the exception).

If it’s true that there now is a chance to change the Oberon language
itself, we’re down to the question, whether it “makes sense”or not.
That’s all there is to it. All arguments appear to be in the table.

Jörg has made a few points on this topic in an earlier post ("currently
a := b is not allowed for VAR a: ARRAY 10 OF CHAR; b: ARRAY 10 CHAR, because
there are several ways to allow this already eg VAR a, b: ARRAY 10 OF CHAR").

On the other hand, I have also been working with Luca’s implementation
of ORP (which fully implements structural equivalence for arrays) for some
time now, I must say that I can’t see any issues with that. It works!
(small addition: not so sure about portability when different compilers
are used, perhaps someone else can chip in here).

Personally I’m indifferent. I can live with the current status quo for
arrays (where assignments of different ARRAY types are only allowed in
the case of open arrays). But I would also accept a relaxation of the
type equivalence rule in that case (knowing how easy it is to implement).

Any additional thoughts?

-AP




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171006/5bc6e2b2/attachment.html>