[Oberon] Case statements containing base type labels

joerg.straube at iaeth.ch joerg.straube at iaeth.ch
Tue Aug 29 09:11:59 CEST 2023


Hi

In the meantime, I implemented 3)
The type extensions in a CASE are only allowed to get broader and broader.
In other words: the extension depth is only allowed to get smaller.

I made the following changes to ORP.Mod.

Parameter “depth” added to
PROCEDURE IsExtension(t0, t1: ORB.Type; VAR depth: INTEGER): BOOLEAN;
   BEGIN (* t1 is an extension of t0 *)
      INC(depth);
      RETURN (t0 = t1) OR (t1 = NIL) & IsExtension(t0, t1.base, depth)
   END IsExtension;

Parameter “depth” added to
PROCEDURE TypeTest(VAR x: ORG.Item; T: ORB.Type; guard: BOOLEAN; VAR depth: INTEGER);

Hierarchy logic added to
PROCEDURE TypeCase(obj: ORB.Object; VAR x: ORG.Item; VAR prvDepth: INTEGER);
   VAR depth: INTEGER;
   BEGIN
…
      depth := 0; TypeTest(x, typobj.type, FALSE, depth); obj.type := typobj.type;
      IF depth > prvDepth THEN ORS.Mark(“type more specific than previous”) END;
      prvDepth := depth
…
   END TypeCase;

and finally in StatSequence: start with an “infinite” depth (I took 9999) and propagate depth from label to label
ELSIF sym = ORS.case
    ….
    IF (orgtype.form = ORB.Pointer) OR (orgtype.form = ORB.Record) & (obj.class = ORB.Par) THEN
       Check(ORS.of); depth := 9999; TypeCase(obj, x, depth); L0 := 0
       WHILE sym = ORS.bar DO
          ORS.Get(sym); ORG.FJump(L0); ORG.Fixup(x); obj.type := orgtype; TypeCase(obj, x, depth)
       END
     …
END

Jörg

Von: Oberon <oberon-bounces at lists.inf.ethz.ch> im Auftrag von Joerg <joerg.straube at iaeth.ch>
Datum: Montag, 28. August 2023 um 23:10
An: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Betreff: Re: [Oberon] Case statements containing base type labels
August

When I saw your code, this was basically my first reaction why I said the CASE label „Shape“ is not allowed as it is no extension.

Then came Diego and said „Shape“ is an extension of itself. He is right as the report explicitely states it. Because I never thought of types with different extension levels, I thought: the missing ELSE could be handled elegantly with this „trick“

Personally, I find the CASE construct seen as a combination of IF-ELSE with implicit WITHs a nice „syntactic sugar“. But I have to agree with Chris, that it’s not obvious that then the order of CASE labels is important!

To define the clear semantic I propse 4 options:
1) state that all extension have to be on the same level aka must have the same „depth“ —> Shape generates an error.

2) state that the „CASE with types“ is a syntactic sugar for an IF-ELSE cascade with implicit WITHs. Basically, leaving the order to the programmer. „Shape“ as last CASE label is an elegant way for an ELSE. But having „Shape“ as first label, makes the labels „Circle“ and „Rectangle“ void.

3) as type extensions build a hierarchy state that in the „CASE with types“ the labes have to be sorted from specific to broader. If a label is a more specific than a previous one, generate an error.

4) state that the compiler sorts the labels from specific to broader. The hierarchy/order is guarateed by the compiler

Looking at these 4 options, I would go for 1) or 3)

br
Jörg

> Am 28.08.2023 um 19:28 schrieb August Karlstrom <fusionfile at gmail.com>:
> On 2023-08-28 15:20, Chris Burrows wrote:
>> Refer to the pair of examples on P 61 of Programming in Oberon, 2014:
>> https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf <https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf>
>
> The examples you refer to in "Programming in Oberon" are in the context of message records and all labels are (proper) direct extensions of the base type Message so there is no ambiguity in this case; the labels can be arranged in any order without affecting the behavior of the case statement (as it should be).
>
> My current conclusion is that a case statement where one type label is an extension of another is not well-defined. I think an ambitious compiler could even reject such a statement, similar to how repeated case labels can be handled.
>
>
> /August
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
--
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/20230829/f49ad4cd/attachment.html>


More information about the Oberon mailing list