August 2023 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Export of Oberon Mail.SendCmd().
by Joerg 30 Oct '26

30 Oct '26

Generally, re-using code instead of copying is a good approach. If you do so, then the whole code of Mail is imported in News. Possible but perhaps there is even a better approach to re-use code. What about this: try to separate all common code in an own module (e.g call it Communication.Mod or MsgBase.Mod or Utilities.Mod or so) and import this new module in Mail and in News. br Jörg > Am 14.06.2023 um 19:53 schrieb peter(a)easthope.ca: > > Hello again, > > Several procedures in Mail are used in Oberon News. Rg.: > Mail.ParseContent(), Mail.DecodeMessage() & Mail.GetSetting(). > > Is export of SendCmd() and use in News objectionable? > Ie. in Mail, change PROCEDURE SendCmd(...) to PROCEDURE SendCmd*(...). > > Thanks, ... P. > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

Good News on Ceres-3 recreated on FPGA
by Pablo Cayuela 21 Oct '23

21 Oct '23

This project of Ceres on FPGA by Udo Möller was mentioned many times on the list. There is some good news on it. http://www.cpu-ns32k.net/News.html The Ceres-3 is finally working on an FPGA board featuring a Verilog version of the NS32k CPU used in the original hardware: http://www.cpu-ns32k.net/TRIPUTER.html#Ceres Ceres-3 in Action, Fig. 10 of http://www.cpu-ns32k.net/Ceres.html http://www.cpu-ns32k.net/images/Ceres-3-5.jpg At "The Web Site to Remember National Semiconductor's Series 32000 Family" http://www.cpu-ns32k.net you can find many retrocomputing projects that Udo Möller has built along the years, http://www.cpu-ns32k.net/TITAN6.html http://www.cpu-ns32k.net/TRIPUTER.html featuring his own reconstruction of the NS32k family of CPUs functionality in Verilog based only on the documentation manuals of the chips. His design is called the M32632, http://www.cpu-ns32k.net/Overview.html http://www.cpu-ns32k.net/Architecture.html and it is working on a series of Altera FPGA boards, http://www.cpu-ns32k.net/Devhard.html that anyone could use: http://www.cpu-ns32k.net/Getting.html I even port one of his initial versions of the M32632 to a Xilinx FPGA (Digilent Nexys4 board) but not the complete Ceres-3 project. I hope you find this news interesting. Best regards, Prof Pablo Cayuela Argentina

2 2

Activate Midle Mouse button for Oberon on Windows 10
by Dieter 09 Sep '23

09 Sep '23

Hi there, I am one of the few fossils still working with *ETH PlugIn Oberon for WindowsTM / Win32 2.5 (18.12.2010) ** ** on Windows 2008 Version 6.1.7600 Glötzel@GLÖTZEL-PC * *Logitech Mouse MS560* I can no longer use the middle mouse key. I did have it running properly some time ago, but meanwhile I forgot the clue. Thanks, Dieter

2 3

Non-matching expressions in case statements
by Andreas Pirklbauer 31 Aug '23

31 Aug '23

> My interpretation is that the presence of the phrase *case label list* indicates > that the remainder of the sentence only applies to numeric case statements. > > The syntax for type case statements is a substantially reduced form of the > syntax for numeric case statements: > > TypeCaseStatement = CASE qualident OF case {"|" case} END. > case = [qualident ":" StatementSequence]. > > NumericCaseStatement = CASE expression OF case {"|" case} END. > case = [CaseLabelList ":" StatementSequence]. > CaseLabelList = LabelRange {"," LabelRange}. > LabelRange = label [".." label]. > label = integer | string | qualident. I agree. And this is not the only difference between the two forms of the case statement. For example: Although the semantics of what happens at run time, when the value (or type) of the case expression (or case variable) does not correspond to any case label (or case label type) in the source text is NOT defined in the Oberon language, an actual compiler implementation may choose two different approaches, e.g., a. For the numeric case statement: the program is aborted b. For the type case statement: no action is taken (e.g., to enable the "fall-through” mechanism in OO settings)

1 0

Non-matching expressions in case statements
by August Karlstrom 31 Aug '23

31 Aug '23

1) For case statements with integer labels, which often represent an enumerated type, it's *desirable* to trap non-matching case expressions as it may indicate a forgotten case label. 2) When using case statements with type labels, the programmer typically relies on non-matching case expressions being ignored; for message records the message "fall through", as described in "Programming in Oberon", p. 61. Here it's *essential* that the implementation does not halt the program with a trap, otherwise this technique will not work. The language report says: "First the case expression is evaluated, then the statement sequence is executed whose case label list contains the obtained value." As I interpret the sentence above, the expression is supposed to match exactly one label, however that is not the case with "fall through" messages. I think it needs to be clarified in the language report that "fall through" is well-defined for case statements with type labels. Any comments? https://people.inf.ethz.ch/wirth/Oberon/PIO.pdf https://miasap.se/obnc/oberon-report.html#sec6.3 Regards, August

2 1

Case statements containing base type labels
by August Karlstrom 30 Aug '23

30 Aug '23

Given the declarations Shape = RECORD x, y: REAL END Rectangle = RECORD (Shape) w, h: REAL END Circle = RECORD (Shape) r: REAL END does a case statement containing labels for all three types have well defined behavior? CASE s OF Rectangle: ... | Circle: ... | Shape: ... END In this case a rectangle and a circle respectively is also a shape so it's not clear what label is selected and the order of the labels should not matter. Regards, August

6 12

Re: [Oberon] Oberon Digest, Vol 231, Issue 7
by dirk muysers 29 Aug '23

29 Aug '23

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(a)lists.inf.ethz.ch<mailto:oberon-request@lists.inf.ethz.ch> Sent: mardi 29 août 2023 12:00 To: oberon(a)lists.inf.ethz.ch<mailto:oberon@lists.inf.ethz.ch> Subject: Oberon Digest, Vol 231, Issue 7 Send Oberon mailing list submissions to oberon(a)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(a)lists.inf.ethz.ch You can reach the person managing the list at oberon-owner(a)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(a)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(a)gmail.com> To: oberon(a)lists.inf.ethz.ch Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <4df8fce8-2156-e403-21e5-b0a4a58a4c07(a)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(a)gcjd.org> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <20230828205120917858.5a21830c(a)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(a)iaeth.ch> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <D085B260-A1DE-4947-A9D5-A34F625B5937(a)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(a)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(a)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(a)iaeth.ch" <joerg.straube(a)iaeth.ch> To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Subject: Re: [Oberon] Case statements containing base type labels Message-ID: <PAWP194MB210299BFCD1EDA11B5CE9EE2AEE7A(a)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(a)lists.inf.ethz.ch> im Auftrag von Joerg <joerg.straube(a)iaeth.ch> Datum: Montag, 28. August 2023 um 23:10 An: ETH Oberon and related systems <oberon(a)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(a)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(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon(a)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/att…> ------------------------------ Message: 5 Date: Tue, 29 Aug 2023 09:43:03 +0200 From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> To: Oberon List <oberon(a)lists.inf.ethz.ch> Cc: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> Subject: [Oberon] Case statements containing base type labels Message-ID: <B619D6F9-161E-4A2D-852F-275A75F603AF(a)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(a)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 **************************************

1 0

Case statements containing base type labels
by Andreas Pirklbauer 29 Aug '23

29 Aug '23

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).

1 0

Re: [Oberon] Case statements containing base type labels
by Joerg 29 Aug '23

29 Aug '23

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(a)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(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

2 1

Re (2): Names in Unix.Oberon.NetSystem.Mod
by peter＠easthope.ca 28 Aug '23

28 Aug '23

From: Joerg <joerg.straube(a)iaeth.ch> Date: Sat, 26 Aug 2023 18:46:04 +0200 > Principally, as neither Password nor PasswordDesc is exported, it‘s > a pure implementation decision how you want to call this > module-internal type. Acknowledged. I don't claim to be a professional programmer but things I write tend to be understandable, to me at least, within a year of writing. As years pass, understanding the reasoning behind code withers. =8~/ For code written by another, I don't have the original reasoning except where it was documented. The "understanding problem" is magnified. The difficulty is mitigated by correct use of natural language. The situation is illustrated by the parallel discussion of the CASE statement. The expert can assert, "I named the variable 'mammal' because it refers to a mammal." For the compiler, the variable might equally well be "whale" or "mammal" or "animal". For the human reader, the choice can be significant but subtle. > Personally, I would only call the set („user“, „password“) „ > Credential“. As you store the host and the service as well, I > would call the bundle of these 4 strings „ServiceLogin“ or „ > ServiceAccess“ or something along these lines. Thanks. English has no specific name for the four-tuple. I can imagine "authenticationFourTuple" but you might find that laughable. With contemporary hardware, the length of the name is probably not objectionable. > But feel free to call it „Credential“, if you like. I'll refrain. You caught a semantic error. Not sure about "authenticationFourTuple". Thanks for the helpful reply, ... P.L. - mobile: +1 778 951 5147 VoIP: +1 604 670 0140

1 0