[Oberon] Oberon Digest, Vol 231, Issue 7
dirk muysers
dmuysers at hotmail.com
Tue Aug 29 18:08:03 CEST 2023
I prefer the very clear solution to this problem in Modula-3:
CASE is for ordinal types
TYPECASE for REF types
WITH to open inner scopes
I really miss them in OBERON
(What I miss in M3 is selectively hiding RECORD fields 😊)
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows
From: oberon-request at lists.inf.ethz.ch<mailto:oberon-request at lists.inf.ethz.ch>
Sent: mardi 29 août 2023 12:00
To: oberon at lists.inf.ethz.ch<mailto:oberon at lists.inf.ethz.ch>
Subject: Oberon Digest, Vol 231, Issue 7
Send Oberon mailing list submissions to
oberon at lists.inf.ethz.ch
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.inf.ethz.ch/mailman/listinfo/oberon
or, via email, send a message with subject or body 'help' to
oberon-request at lists.inf.ethz.ch
You can reach the person managing the list at
oberon-owner at lists.inf.ethz.ch
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Oberon digest..."
Today's Topics:
1. Re: Case statements containing base type labels (August Karlstrom)
2. Re: Case statements containing base type labels (chris)
3. Re: Case statements containing base type labels (Joerg)
4. Re: Case statements containing base type labels
(joerg.straube at iaeth.ch)
5. Case statements containing base type labels (Andreas Pirklbauer)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Aug 2023 19:27:44 +0200
From: August Karlstrom <fusionfile at gmail.com>
To: oberon at lists.inf.ethz.ch
Subject: Re: [Oberon] Case statements containing base type labels
Message-ID: <4df8fce8-2156-e403-21e5-b0a4a58a4c07 at gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
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
------------------------------
Message: 2
Date: Mon, 28 Aug 2023 20:51:20 +0200
From: chris <chris at gcjd.org>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Case statements containing base type labels
Message-ID: <20230828205120917858.5a21830c at gcjd.org>
Content-Type: text/plain; charset=iso-8859-1
On Mon, 28 Aug 2023 19:27:44 +0200, August Karlstrom wrote:
> My current conclusion is that a case statement where one type label
> is an extension of another is not well-defined.
I agree. IMHO it was a bad idea to mix the WITH statement and the CASE
statement at all.
The WITH statement was defined by IF/ELSIF so no problem here:
For example in "Object-Oriented Programming in Oberon-2" (M?ssenb?ck
1993) Appendix A:
"WITH v: T1 DO S1 | v: T2 DO S2 ELSE S3 END
has the following meaning: if the dynamic type of v is T1, then the
statement sequence S1 is executed, where v is regarded as if it had the
static type T1; else if the dynamic type of v is T2, then S2 is
executed, where v is regarded as if it had the static type T2; else S3
is executed. T1 and T2 must be extensions of T0."
As explained by Wirth in "Differences between Revised Oberon and
Oberon" (Wirth 2011)
"The case statement performs the same function as the if statement.
However, it is intended to use a different technique of implementation,
namely a single, indexed branch instead of a cascade of conditional
branches."
The 2011 version of Oberon-07 only allows INTEGER and CHAR for CASE
statements.
Mixing with type tests makes no sense as they will most likely be
implemented as several IF - ELSIF statements.
> I think an ambitious
> compiler could even reject such a statement, similar to how repeated
> case labels can be handled.
I think it should reject such code as the case labels are not distinct
from each other. Otherwise the semantics of the CASE statement would
change for this case from the original intention and the other variant
with INTEGER/CHAR labels which must be distinct.
Greetings, chris
------------------------------
Message: 3
Date: Mon, 28 Aug 2023 23:09:21 +0200
From: Joerg <joerg.straube at iaeth.ch>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Case statements containing base type labels
Message-ID: <D085B260-A1DE-4947-A9D5-A34F625B5937 at iaeth.ch>
Content-Type: text/plain; charset=utf-8
?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
------------------------------
Message: 4
Date: Tue, 29 Aug 2023 07:11:59 +0000
From: "joerg.straube at iaeth.ch" <joerg.straube at iaeth.ch>
To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
Subject: Re: [Oberon] Case statements containing base type labels
Message-ID:
<PAWP194MB210299BFCD1EDA11B5CE9EE2AEE7A at PAWP194MB2102.EURP194.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset="utf-8"
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-0001.html>
------------------------------
Message: 5
Date: Tue, 29 Aug 2023 09:43:03 +0200
From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
To: Oberon List <oberon at lists.inf.ethz.ch>
Cc: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
Subject: [Oberon] Case statements containing base type labels
Message-ID: <B619D6F9-161E-4A2D-852F-275A75F603AF at yahoo.com>
Content-Type: text/plain; charset=utf-8
Isn?t the problem that the evaluation order of the Oberon ?type" case statement (CASE p OF basetype .. | extendedtype.. | .. END) is not well defined. This inevitably means that different compilers will (necessarily) end up implementing different semantics.. which is bad.
In my view:
a) The type case statement should never have been merged with the ?numerical? case statement - not because it makes the parser a little bit easier, but mainly because they are in fact separate statements.
b) The evaluation order of labels should be defined in the language - the order doesn?t necessarily have to be declaration order, it could for example also be defined by the type hierarchy itself (e.g. highest extension level first).
------------------------------
Subject: Digest Footer
--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
------------------------------
End of Oberon Digest, Vol 231, Issue 7
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20230829/2f5fa5e8/attachment.html>
More information about the Oberon
mailing list