<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="FR" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">I prefer the very clear solution to this problem in Modula-3:<br>
CASE is for ordinal types<br>
TYPECASE for REF types<br>
WITH to open inner scopes<br>
I really miss them in OBERON</span></p>
<p class="MsoNormal">(What I miss in M3 is selectively hiding RECORD fields <span style="font-family:"Segoe UI Emoji",sans-serif">😊</span>)</p>
<p class="MsoNormal">Sent from <a href="https://go.microsoft.com/fwlink/?LinkId=550986">
Mail</a> for Windows</p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="mso-element:para-border-div;border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="border:none;padding:0cm"><b>From: </b><a href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.ch</a><br>
<b>Sent: </b>mardi 29 août 2023 12:00<br>
<b>To: </b><a href="mailto:oberon@lists.inf.ethz.ch">oberon@lists.inf.ethz.ch</a><br>
<b>Subject: </b>Oberon Digest, Vol 231, Issue 7</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Send Oberon mailing list submissions to<br>
oberon@lists.inf.ethz.ch<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
or, via email, send a message with subject or body 'help' to<br>
oberon-request@lists.inf.ethz.ch<br>
<br>
You can reach the person managing the list at<br>
oberon-owner@lists.inf.ethz.ch<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Oberon digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: Case statements containing base type labels (August Karlstrom)<br>
2. Re: Case statements containing base type labels (chris)<br>
3. Re: Case statements containing base type labels (Joerg)<br>
4. Re: Case statements containing base type labels<br>
(joerg.straube@iaeth.ch)<br>
5. Case statements containing base type labels (Andreas Pirklbauer)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Mon, 28 Aug 2023 19:27:44 +0200<br>
From: August Karlstrom <fusionfile@gmail.com><br>
To: oberon@lists.inf.ethz.ch<br>
Subject: Re: [Oberon] Case statements containing base type labels<br>
Message-ID: <4df8fce8-2156-e403-21e5-b0a4a58a4c07@gmail.com><br>
Content-Type: text/plain; charset=UTF-8; format=flowed<br>
<br>
On 2023-08-28 15:20, Chris Burrows wrote:<br>
> Refer to the pair of examples on P 61 of Programming in Oberon, 2014:<br>
> <br>
> <a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a>
<br>
> <<a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a>><br>
<br>
The examples you refer to in "Programming in Oberon" are in the context <br>
of message records and all labels are (proper) direct extensions of the <br>
base type Message so there is no ambiguity in this case; the labels can <br>
be arranged in any order without affecting the behavior of the case <br>
statement (as it should be).<br>
<br>
My current conclusion is that a case statement where one type label is <br>
an extension of another is not well-defined. I think an ambitious <br>
compiler could even reject such a statement, similar to how repeated <br>
case labels can be handled.<br>
<br>
<br>
/August<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Mon, 28 Aug 2023 20:51:20 +0200<br>
From: chris <chris@gcjd.org><br>
To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br>
Subject: Re: [Oberon] Case statements containing base type labels<br>
Message-ID: <20230828205120917858.5a21830c@gcjd.org><br>
Content-Type: text/plain; charset=iso-8859-1<br>
<br>
On Mon, 28 Aug 2023 19:27:44 +0200, August Karlstrom wrote:<br>
> My current conclusion is that a case statement where one type label <br>
> is an extension of another is not well-defined.<br>
<br>
I agree. IMHO it was a bad idea to mix the WITH statement and the CASE <br>
statement at all.<br>
<br>
The WITH statement was defined by IF/ELSIF so no problem here:<br>
<br>
For example in "Object-Oriented Programming in Oberon-2" (M?ssenb?ck <br>
1993) Appendix A:<br>
<br>
"WITH v: T1 DO S1 | v: T2 DO S2 ELSE S3 END<br>
has the following meaning: if the dynamic type of v is T1, then the <br>
statement sequence S1 is executed, where v is regarded as if it had the <br>
static type T1; else if the dynamic type of v is T2, then S2 is <br>
executed, where v is regarded as if it had the static type T2; else S3 <br>
is executed. T1 and T2 must be extensions of T0."<br>
<br>
As explained by Wirth in "Differences between Revised Oberon and <br>
Oberon" (Wirth 2011)<br>
"The case statement performs the same function as the if statement. <br>
However, it is intended to use a different technique of implementation, <br>
namely a single, indexed branch instead of a cascade of conditional <br>
branches."<br>
<br>
The 2011 version of Oberon-07 only allows INTEGER and CHAR for CASE <br>
statements.<br>
<br>
Mixing with type tests makes no sense as they will most likely be <br>
implemented as several IF - ELSIF statements.<br>
<br>
> I think an ambitious <br>
> compiler could even reject such a statement, similar to how repeated <br>
> case labels can be handled.<br>
<br>
I think it should reject such code as the case labels are not distinct <br>
from each other. Otherwise the semantics of the CASE statement would <br>
change for this case from the original intention and the other variant <br>
with INTEGER/CHAR labels which must be distinct.<br>
<br>
Greetings, chris<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 28 Aug 2023 23:09:21 +0200<br>
From: Joerg <joerg.straube@iaeth.ch><br>
To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br>
Subject: Re: [Oberon] Case statements containing base type labels<br>
Message-ID: <D085B260-A1DE-4947-A9D5-A34F625B5937@iaeth.ch><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
?August<br>
<br>
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.<br>
<br>
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?
<br>
<br>
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!<br>
<br>
To define the clear semantic I propse 4 options:<br>
1) state that all extension have to be on the same level aka must have the same ?depth? ?> Shape generates an error.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4) state that the compiler sorts the labels from specific to broader. The hierarchy/order is guarateed by the compiler<br>
<br>
Looking at these 4 options, I would go for 1) or 3)<br>
<br>
br<br>
J?rg<br>
<br>
> Am 28.08.2023 um 19:28 schrieb August Karlstrom <fusionfile@gmail.com>:<br>
> ?On 2023-08-28 15:20, Chris Burrows wrote:<br>
>> Refer to the pair of examples on P 61 of Programming in Oberon, 2014:<br>
>> <a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a> <<a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a>><br>
> <br>
> 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).<br>
> <br>
> 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.<br>
> <br>
> <br>
> /August<br>
> --<br>
> Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 29 Aug 2023 07:11:59 +0000<br>
From: "joerg.straube@iaeth.ch" <joerg.straube@iaeth.ch><br>
To: ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br>
Subject: Re: [Oberon] Case statements containing base type labels<br>
Message-ID:<br>
<PAWP194MB210299BFCD1EDA11B5CE9EE2AEE7A@PAWP194MB2102.EURP194.PROD.OUTLOOK.COM><br>
<br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi<br>
<br>
In the meantime, I implemented 3)<br>
The type extensions in a CASE are only allowed to get broader and broader.<br>
In other words: the extension depth is only allowed to get smaller.<br>
<br>
I made the following changes to ORP.Mod.<br>
<br>
Parameter ?depth? added to<br>
PROCEDURE IsExtension(t0, t1: ORB.Type; VAR depth: INTEGER): BOOLEAN;<br>
BEGIN (* t1 is an extension of t0 *)<br>
INC(depth);<br>
RETURN (t0 = t1) OR (t1 = NIL) & IsExtension(t0, t1.base, depth)<br>
END IsExtension;<br>
<br>
Parameter ?depth? added to<br>
PROCEDURE TypeTest(VAR x: ORG.Item; T: ORB.Type; guard: BOOLEAN; VAR depth: INTEGER);<br>
<br>
Hierarchy logic added to<br>
PROCEDURE TypeCase(obj: ORB.Object; VAR x: ORG.Item; VAR prvDepth: INTEGER);<br>
VAR depth: INTEGER;<br>
BEGIN<br>
?<br>
depth := 0; TypeTest(x, typobj.type, FALSE, depth); obj.type := typobj.type;<br>
IF depth > prvDepth THEN ORS.Mark(?type more specific than previous?) END;<br>
prvDepth := depth<br>
?<br>
END TypeCase;<br>
<br>
and finally in StatSequence: start with an ?infinite? depth (I took 9999) and propagate depth from label to label<br>
ELSIF sym = ORS.case<br>
?.<br>
IF (orgtype.form = ORB.Pointer) OR (orgtype.form = ORB.Record) & (obj.class = ORB.Par) THEN<br>
Check(ORS.of); depth := 9999; TypeCase(obj, x, depth); L0 := 0<br>
WHILE sym = ORS.bar DO<br>
ORS.Get(sym); ORG.FJump(L0); ORG.Fixup(x); obj.type := orgtype; TypeCase(obj, x, depth)<br>
END<br>
?<br>
END<br>
<br>
J?rg<br>
<br>
Von: Oberon <oberon-bounces@lists.inf.ethz.ch> im Auftrag von Joerg <joerg.straube@iaeth.ch><br>
Datum: Montag, 28. August 2023 um 23:10<br>
An: ETH Oberon and related systems <oberon@lists.inf.ethz.ch><br>
Betreff: Re: [Oberon] Case statements containing base type labels<br>
August<br>
<br>
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.<br>
<br>
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?<br>
<br>
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!<br>
<br>
To define the clear semantic I propse 4 options:<br>
1) state that all extension have to be on the same level aka must have the same ?depth? ?> Shape generates an error.<br>
<br>
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.<br>
<br>
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.<br>
<br>
4) state that the compiler sorts the labels from specific to broader. The hierarchy/order is guarateed by the compiler<br>
<br>
Looking at these 4 options, I would go for 1) or 3)<br>
<br>
br<br>
J?rg<br>
<br>
> Am 28.08.2023 um 19:28 schrieb August Karlstrom <fusionfile@gmail.com>:<br>
> ?On 2023-08-28 15:20, Chris Burrows wrote:<br>
>> Refer to the pair of examples on P 61 of Programming in Oberon, 2014:<br>
>> <a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a> <<a href="https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf">https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf</a>><br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
><br>
> /August<br>
> --<br>
> Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems<br>
> <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
--<br>
Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20230829/f49ad4cd/attachment-0001.html">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20230829/f49ad4cd/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 29 Aug 2023 09:43:03 +0200<br>
From: Andreas Pirklbauer <andreas_pirklbauer@yahoo.com><br>
To: Oberon List <oberon@lists.inf.ethz.ch><br>
Cc: Andreas Pirklbauer <andreas_pirklbauer@yahoo.com><br>
Subject: [Oberon] Case statements containing base type labels<br>
Message-ID: <B619D6F9-161E-4A2D-852F-275A75F603AF@yahoo.com><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
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.<br>
<br>
In my view:<br>
<br>
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.<br>
<br>
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).<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
--<br>
Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Oberon Digest, Vol 231, Issue 7<br>
**************************************<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>