[Oberon] Clarifying type compatibility in Oberon-07

[Luca Boasso]

I have found and old email where I asked Prof. Wirth the following:

"I would like to know the reasoning behind the departure from array name
equivalence in favour of array structural equivalence.
i.e  these two types are equivalent in Oberon-07 but not in Oberon-90

TYPE A = ARRAY 3 OF INTEGER;
          B = ARRAY 3 OF INTEGER;

Could you explain why you decided to change the language in this regard?"

He replied saying that he does not remember the the exact circumstances, as
the change was several years ago.
He continued that the most obvious reason is that one needs less often to
declare named types.

So I agree with Артур Ефимов, probably Wirth will update the language
report soon.

The changes I made in ORP.Mod regarding arrays are to enable the assignment
"i := j;" below

MODULE Arrays2;
  TYPE T = ARRAY 3, 2 OF INTEGER;

  VAR
    a: ARRAY 4 OF T;
    b: ARRAY 4 OF T;
    i: ARRAY 4, 3, 2 OF INTEGER;
    j: ARRAY 4, 3, 2 OF INTEGER;

BEGIN
  a := b; (* this works *)
  i := j; (* this should work, but illegal assignment in Wirth's Oberon *)
END Arrays2.

With the current ORP.Mod on Wirth's website, structural equivalence of
arrays is half baked as it stops at the first array dimension.
In my fix I use the following procedure, that does a full structural check.

  (* Type Rule I.1, I.2, I.4 *)
  PROCEDURE SameArrays(t0, t1: ORB.Type): BOOLEAN;
  BEGIN
    RETURN (t0 = t1)
           OR (t0.form = ORB.Array) & (t1.form = ORB.Array) & (t0.len =
t1.len) &
              SameArrays(t0.base, t1.base)
  END SameArrays;

Regards,
Luca


On Oct 6, 2017 06:57, "August Karlstrom" <fusionfile at gmail.com> wrote:

> On 2017-10-06 12:19, Andreas Pirklbauer wrote:
>
>> every procedure used as an actual parameter would have to be given an
>> explicit name, >
>>
> I'm not sure what you mean here. Can you clarify?
>
> 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).
>>
> I agree with this. I primarily just want to know which features I can rely
> on.
>
>
> -- August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20171006/e831d9da/attachment.html>