[Oberon] Case statements containing base type labels

[Joerg]

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