May 2021 - Oberon - mailman3.inf.ethz.ch

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 16 May '21

16 May '21

Hi Luca, You are about half way through in convincing me.. ;-) .. and now that there is an easy way (i.e. 5 lines of code) to get rid of the “invalid import order” restriction also in the PO 2013 compiler (i.e. without having to make more elaborate changes as in oberonc/Griesemer’s approach), it’s tempting indeed. > 2. It breaks encapsulation. If I (module B) import a module, > A, I should only care about its public interface, not how it > is implemented. So if the module A re-imports types and > indirectly could mess with the import order of my module B, > we have implementation details leaking through. So when > the implementation changes the import order of the client > modules could break. That is a strong argument indeed! In essence, what you’re saying is that the very postulate of “modular programming” itself is violated here (namely that changes in the implementation of A should not necessitate the recompilation - or in this case even the re-editing (!) of the import list - of a client module B) . Although one can also view the re-exported types of A as *part* of its interface, in the sense that if A is modified such that it now also re-exports types from another module (that it previously didn’t re-export), the “interface” of A *does* actually change - surely the symbol file of A does. Thus, a client B must - at the minimum - be recompiled anyway. It just happens not to be the “public” part of A's interface that changes, but only the “hidden” part (=list of re-exported types). So.in principle, this should not be great cause for great concern, weren’t it for the fact that (the import list of) module B may now also have to be edited (!) before it can be re-compiled. * * * The crux is: It’s the fact that the re-import mechanism is a *hidden* mechanism (i.e. not in the spirit of Oberon) that causes much of the issue. PS: I have experimented with - and even implemented - a few possible ways to try to solve the root cause of the issue instead of tinkering with its symptoms, i.e. to get rid of the re-import mechanism altogether.. e.g. by explicitly marking re-exported types in the source file or something.. ..but I just couldn’t do it (at least not in a satisfactory manner). -ap

1 0

Re (n): Streams.
by peter＠easthope.ca 16 May '21

16 May '21

>From eas lab lab.eas at gmail.com Tue May 4 06:18:55 CEST 2021 > Can aos do: > list the 22 most recentcy-ordered > including <dotted files> in /tmp ? > eg.*nix: ls -ta /tmp | head -22 From: Joerg <joerg.straube(a)iaeth.ch> Date: Thu, 13 May 2021 09:33:24 +0200 > When you run linux virtualized on top of a windows machine, why > would you want linux to have a windows console? Windows wasn't mentioned. Chris has UnixAos on a Unix-like system running directly on a PC. Correct? If Chris has A2 on the native machine, Tools > Secure Shell can provide a console on a remote or external *nix system. Either way a command such as ls -ta /tmp | head -22 can execute with the result available in the console for another calculation. Regards, ... P. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

3 2

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 16 May '21

16 May '21

Ok, so before I respond to more emails on this topic off-forum, I have now uploaded the various variants (some have been suggested by others) to implement the compiler’s import handler to: https://github.com/andreaspirklbauer/Oberon-module-imports Variant1 (ORB1.Mod): - "conflict with re-import" if a module M is first re-imported, and then M is used as an alias - "conflict with alias" if M is first used as an alias name, and then module M is re-imported - "invalid import order" if a module M is first re-imported and then explicitly imported Variant 2 (ORB2.Mod): - hidden re-imports can peacefully coexist with aliases - "invalid import order" if a module M is first re-imported and then explicitly imported Variant (ORB3.Mod): - no more restrictions at all, i.e. can import modules in *any* order. * * * All of these variants differ only by a few lines of code (i.e. zero cost, and there is no need for module anchors or GModtab's, etc as in Griesermer’s approach). It’s now a matter of taste which variant to pick. Personally I’m currently (but that may change) leaning towards variant ORB2, i.e. I intentionally leave the “invalid import order” restriction in the compiler. Why? Because I view it is a desirable property if the compiler, if it encourages the programmer to write the import list of a module in the “right” order, i.e. reflecting the module hierarchy.. fully knowing that enforcing the rule that explicit imports must always become before re-imports may in some (rare?) cases force the programmer of a client module to change the import order, if the programmer of an imported module changes *its* import list. I understand that some people feel more strongly about this restriction and absolutely want to be able to write the module list in the IMPORT statement in *any* order -> well, they can now just pick variant ORB3.Mod if they want. -ap

3 2

PO 2013 allows one to "override" predefined procedures and functions
by Andreas Pirklbauer 15 May '21

15 May '21

Thanks, Josef, I can now see how such a “feature” might actually be useful (although I’ve never used it nor did I know it has apparently existed all along since Pascal days). So I resist the temptation.. -Andreas > Standard procedures in Oberon live in the outmost (global) scope on purpose > and the reason is extensibility. It makes it possible to add new procedures > later without invalidating any existing programs. This is so in all Pascal > style languages and their successors. It is very cheap to implement in the > compiler and fits well with the nesting of scopes. Overriding such > procedures locally is thereby possible but used mainly when a new procedure> > happens to be added in a new language version or dialect and an object with > the same name already exists in a program. The locally defined name then > shadows the same name in the global scope and the program compiles and runs > as before. > > I would not recommend to remove this feature. > > - Josef

1 0

PO 2013 allows one to "override" predefined procedures and functions
by Josef Templ 15 May '21

15 May '21

Standard procedures in Oberon live in the outmost (global) scope on purpose and the reason is extensibility. It makes it possible to add new procedures later without invalidating any existing programs. This is so in all Pascal style languages and their successors. It is very cheap to implement in the compiler and fits well with the nesting of scopes. Overriding such procedures locally is thereby possible but used mainly when a new procedure happens to be added in a new language version or dialect and an object with the same name already exists in a program. The locally defined name then shadows the same name in the global scope and the program compiles and runs as before. I would not recommend to remove this feature. - Josef <oberon-request(a)lists.inf.ethz.ch> schrieb am Sa., 15. Mai 2021, 12:00: > 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. PO 2013 allows one to "override" predefined procedures and > functions (Andreas Pirklbauer) > 2. Re: [EXT] PO 2013 allows one to "override" predefined > procedures and functions (Skulski, Wojciech) > 3. PO 2013 allows one to "override" predefined procedures and > functions (Andreas Pirklbauer) > 4. Re: PO 2013 allows one to "override" predefined procedures > and functions (Diego Sardina) > 5. Re: PO 2013 allows one to "override" predefined procedures > and functions (J?rg) > 6. RiskOne ordered (Skulski, Wojciech) > 7. Re: RiskOne ordered (peter(a)easthope.ca) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 May 2021 15:29:21 +0200 > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > To: Oberon List <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <7012460B-DB79-4945-BA61-8FD9CF5603E3(a)yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > > > > ------------------------------ > > Message: 2 > Date: Fri, 14 May 2021 14:00:35 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] [EXT] PO 2013 allows one to "override" > predefined procedures and functions > Message-ID: > < > SN6PR07MB41575CDB194A6063310CA849FF509(a)SN6PR07MB4157.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="Windows-1252" > > Andreas: > > what a great feature. It could be really useful in the hands of a creative > programmer. I am wondering, what would be the run time behavior of this > feature. A crash? > > How did you find this feature? Would be good to get rid of it. > > Wojtek > ________________________________________ > From: Oberon [oberon-bounces(a)lists.inf.ethz.ch] on behalf of Andreas > Pirklbauer [andreas_pirklbauer(a)yahoo.com] > Sent: Friday, May 14, 2021 9:29 AM > To: Oberon List > Subject: [EXT] [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mail… > > > ------------------------------ > > Message: 3 > Date: Fri, 14 May 2021 16:19:46 +0200 > From: Andreas Pirklbauer <andreas_pirklbauer(a)yahoo.com> > To: Oberon List <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <B0FC842A-6CDA-40F8-A607-3A529EFFC203(a)yahoo.com> > Content-Type: text/plain; charset=utf-8 > > Wojtek, > > The run time behaviour of this ?feature? is to simply override the > predefined identifier, which then is > no longer available in the current scope. So no crash. One can even > override things like INTEGER, etc. > > Actually, the compiler itself does some overriding in this way, namely > with the three procedures > ORG.ADC, ORG.SBC, ORB.UML. Inside these three procedures the corresponding > predefined > identifier (ADC, SBC or UML) is of course not available. > > To disallow this kind of ?overrriding? in the compiler, one could for > example: > > 1. Rename ORG.ADC, ORG.SBC, ORB.UML to ORG.Adc, ORG.Sbc, ORB.Uml > > 2. Adapt ORP.StandFunc accordingly to use the new procedure names > > 3. Adapt ORB.NewObj such that it now also checks the predefined > identifiers as follows: > > x := universe; > WHILE (x # NIL) & (x.name # id) DO x := x.next END ; > IF x = NIL THEN (*...ok...*) ELSE ORS.Mark("predefined identifier?) END > > to arrive at something along the lines of: > > PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER); > (*insert new Object with name id*) > VAR new, x: Object; > BEGIN x := universe.next; > WHILE (x # NIL) & (x.name # id) DO x := x.next END ; > IF x = NIL THEN x := topScope; > WHILE (x.next # NIL) & (x.next.name # id) DO x := x.next END ; > IF x.next = NIL THEN > NEW(new); new.name := id; new.class := class; new.next := NIL; > new.rdo := FALSE; new.dsc := NIL; > x.next := new; obj := new > ELSE obj := x.next; ORS.Mark("mult def") > END > ELSE ORS.Mark("predefined identifier") > END > END NewObj; > > PS: When doing this, the impact on the compiler?s performance is about > 5-10%. > > -ap > > > > Andreas: > > > > what a great feature. It could be really useful in the hands of a > creative programmer. I am wondering, what would be the run time behavior of > this feature. A crash? > > > > How did you find this feature? Would be good to get rid of it. > > > > Wojtek > ________________________________________ > From: Oberon [ > oberon-bounces at lists.inf.ethz.ch] on behalf of Andreas Pirklbauer > [andreas_pirklbauer at yahoo.com > ] > Sent: Friday, May 14, 2021 9:29 AM > To: Oberon List > Subject: [EXT] [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > > Has anyone noticed that the PO 2013 allows the programmer > to ?overrride? predefined procedures and functions, e.g., > > MODULE M; > VAR > INC: CHAR; > i: INTEGER; > BEGIN > INC := "a?; > INC(i) (*not a procedure*) > END M. > > This should not be allowed.. > > ------------------------------ > > Message: 4 > Date: Fri, 14 May 2021 16:14:16 +0200 > From: "Diego Sardina" <dsar(a)eml.cc> > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <abd70680-9ba8-4a38-9e4e-ba426b8757e3(a)www.fastmail.com> > Content-Type: text/plain;charset=utf-8 > > On Fri, May 14, 2021, at 3:29 PM, Andreas Pirklbauer wrote: > > Has anyone noticed that the PO 2013 allows the programmer > > to ?overrride? predefined procedures and functions, e.g., > > > > MODULE M; > > VAR > > INC: CHAR; > > i: INTEGER; > > BEGIN > > INC := "a?; > > INC(i) (*not a procedure*) > > END M. > > > > This should not be allowed.. > > > > For what I remember in Oberon every predefined identifier can be > overridden since always. > > This is the reason TRUE and FALSE were promoted to keyword in Oberon-07, > to avoid CONST TRUE = FALSE. > > But I agree that this shouldn't be allowed (and that promotion to keyword > is debatable). > > -- > Diego Sardina > > > ------------------------------ > > Message: 5 > Date: Fri, 14 May 2021 16:25:11 +0200 > From: J?rg <joerg.straube(a)iaeth.ch> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: Re: [Oberon] PO 2013 allows one to "override" predefined > procedures and functions > Message-ID: <175B9254-7AF3-48FE-AE31-BB0C41459FB6(a)iaeth.ch> > Content-Type: text/plain; charset=utf-8 > > > > Gruss, J?rg > > > Am 14.05.2021 um 16:23 schrieb Diego Sardina <dsar(a)eml.cc>: > > > > ?On Fri, May 14, 2021, at 3:29 PM, Andreas Pirklbauer wrote: > >> Has anyone noticed that the PO 2013 allows the programmer > >> to ?overrride? predefined procedures and functions, e.g., > >> > >> MODULE M; > >> VAR > >> INC: CHAR; > >> i: INTEGER; > >> BEGIN > >> INC := "a?; > >> INC(i) (*not a procedure*) > >> END M. > >> > >> This should not be allowed.. > >> > > > > For what I remember in Oberon every predefined identifier can be > overridden since always. > > > > This is the reason TRUE and FALSE were promoted to keyword in Oberon-07, > to avoid CONST TRUE = FALSE. > > > > But I agree that this shouldn't be allowed (and that promotion to > keyword is debatable). > > > > -- > > Diego Sardina > > -- > > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > > https://lists.inf.ethz.ch/mailman/listinfo/oberon > > > ------------------------------ > > Message: 6 > Date: Fri, 14 May 2021 15:28:14 +0000 > From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> > To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> > Subject: [Oberon] RiskOne ordered > Message-ID: > < > SN6PR07MB4157574B3A984FAADF19B383FF509(a)SN6PR07MB4157.namprd07.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > All: > > I ordered production of two prototype RiskOne motherboards. If anyone > want to have those, it is the last minute to tell me so I can possibly add > more boards to the order. You need to do it today. The cost will be $500 > per board. > > The features: > Spartan-6 LX25, > 4 MB of ZBT RAM, > 16 MB HyperRAM (so it is 20 MB total). I intend to use HyperRAM for video, > but it can be used for anything else. > HDMI connector to output video > PS2 mouse and keyboard > W5500 chip for Ethernet with the RJ-45 socket. > Three serial ports. One of these can be optionally operated as "optical > interface" at 50 MHz. > Connector for the Nordic NRF24L01 radio, same as PO 2013. > Connector for Wi-Fi Sparkfun WRL-13678. > Two SD cards. One micro, one full. This is to adopt Chris file system > HCFiler with one of these. > Three PMOD connectors. > One set of expansion connectors for the daughter card "shield". > -- I already designed the ADC shield, which is my primary interest. > -- The shield can be anything: ADC, DAC, industrial PID control, > anything. > > I would have attached the full spec sheet, but this will hold off the > posting for approval. > > > > ------------------------------ > > Message: 7 > Date: Fri, 14 May 2021 10:17:11 -0700 > From: peter(a)easthope.ca > To: oberon(a)lists.inf.ethz.ch > Subject: Re: [Oberon] RiskOne ordered > Message-ID: <E1lhbR1-0001Dh-8B(a)joule.invalid> > > Hi Wojciech, > > > I ordered production of two prototype RiskOne motherboards. If > > anyone want to have those, it is the last minute to tell me so I can > > possibly add more boards to the order. You need to do it today. The > > cost will be $500 per board. > > Good news. I thought of asking about progress but better to refrain > from bothering you. > > Please order one at my expense. No rush to receive it. As described > earlier, it's an investment. Can convert 500 US to Canadian dollars > and mail a paper cheque to your campus address. Is Interac used > there? Might be Canada only. World Remit is international and I use > it routinely. If you prefer another means of payment, just let me > know. > > Thanks! ... P. > > -- > tel: +1 604 670 0140 Bcc: peter at easthope. ca > > > > ------------------------------ > > 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 204, Issue 11 > *************************************** >

2 1

Re: [Oberon] RiskOne ordered
by peter＠easthope.ca 14 May '21

14 May '21

Hi Wojciech, > I ordered production of two prototype RiskOne motherboards. If > anyone want to have those, it is the last minute to tell me so I can > possibly add more boards to the order. You need to do it today. The > cost will be $500 per board. Good news. I thought of asking about progress but better to refrain from bothering you. Please order one at my expense. No rush to receive it. As described earlier, it's an investment. Can convert 500 US to Canadian dollars and mail a paper cheque to your campus address. Is Interac used there? Might be Canada only. World Remit is international and I use it routinely. If you prefer another means of payment, just let me know. Thanks! ... P. -- tel: +1 604 670 0140 Bcc: peter at easthope. ca

1 0

PO 2013 allows one to "override" predefined procedures and functions
by Andreas Pirklbauer 14 May '21

14 May '21

Wojtek, The run time behaviour of this “feature” is to simply override the predefined identifier, which then is no longer available in the current scope. So no crash. One can even override things like INTEGER, etc. Actually, the compiler itself does some overriding in this way, namely with the three procedures ORG.ADC, ORG.SBC, ORB.UML. Inside these three procedures the corresponding predefined identifier (ADC, SBC or UML) is of course not available. To disallow this kind of “overrriding” in the compiler, one could for example: 1. Rename ORG.ADC, ORG.SBC, ORB.UML to ORG.Adc, ORG.Sbc, ORB.Uml 2. Adapt ORP.StandFunc accordingly to use the new procedure names 3. Adapt ORB.NewObj such that it now also checks the predefined identifiers as follows: x := universe; WHILE (x # NIL) & (x.name # id) DO x := x.next END ; IF x = NIL THEN (*...ok...*) ELSE ORS.Mark("predefined identifier”) END to arrive at something along the lines of: PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER); (*insert new Object with name id*) VAR new, x: Object; BEGIN x := universe.next; WHILE (x # NIL) & (x.name # id) DO x := x.next END ; IF x = NIL THEN x := topScope; WHILE (x.next # NIL) & (x.next.name # id) DO x := x.next END ; IF x.next = NIL THEN NEW(new); new.name := id; new.class := class; new.next := NIL; new.rdo := FALSE; new.dsc := NIL; x.next := new; obj := new ELSE obj := x.next; ORS.Mark("mult def") END ELSE ORS.Mark("predefined identifier") END END NewObj; PS: When doing this, the impact on the compiler’s performance is about 5-10%. -ap > Andreas: > > what a great feature. It could be really useful in the hands of a creative programmer. I am wondering, what would be the run time behavior of this feature. A crash? > > How did you find this feature? Would be good to get rid of it. > > Wojtek ________________________________________ From: Oberon [ oberon-bounces at lists.inf.ethz.ch] on behalf of Andreas Pirklbauer [andreas_pirklbauer at yahoo.com ] Sent: Friday, May 14, 2021 9:29 AM To: Oberon List Subject: [EXT] [Oberon] PO 2013 allows one to "override" predefined procedures and functions Has anyone noticed that the PO 2013 allows the programmer to “overrride” predefined procedures and functions, e.g., MODULE M; VAR INC: CHAR; i: INTEGER; BEGIN INC := "a”; INC(i) (*not a procedure*) END M. This should not be allowed..

2 1

PO 2013 allows one to "override" predefined procedures and functions
by Andreas Pirklbauer 14 May '21

14 May '21

Has anyone noticed that the PO 2013 allows the programmer to “overrride” predefined procedures and functions, e.g., MODULE M; VAR INC: CHAR; i: INTEGER; BEGIN INC := "a”; INC(i) (*not a procedure*) END M. This should not be allowed..

4 3

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 14 May '21

14 May '21

> […] A similar situation occurs, when hidden re-imports clash with alias names. Thanks to all for the various emails on this topic. Below is a fix for this topic as well: One simply skips re-imports (~obj.rdo) in NewObj, thisObj *and* now also in ThisModule, and simultaneously allows re-imports and aliases to co-exist: PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER); (*insert new Object with name id*) VAR new, x: Object; BEGIN x := topScope; WHILE (x.next # NIL) & ((x.next.name # id) OR (x.next.class = Mod) & ~x.next.rdo) DO x := x.next END ; IF x.next = NIL THEN NEW(new); new.name := id; new.class := class; new.next := NIL; new.rdo := FALSE; new.dsc := NIL; x.next := new; obj := new ELSE obj := x.next; ORS.Mark("mult def") END END NewObj; PROCEDURE thisObj*(): Object; VAR s, x: Object; BEGIN s := topScope; REPEAT x := s.next; WHILE (x # NIL) & ((x.name # ORS.id) OR (x.class = Mod) & ~x.rdo) DO x := x.next END ; s := s.dsc UNTIL (x # NIL) OR (s = NIL); RETURN x END thisObj; PROCEDURE ThisModule(name, orgname: ORS.Ident; decl: BOOLEAN; key: LONGINT): Object; VAR mod: Module; obj, obj1: Object; BEGIN obj1 := topScope; obj := obj1.next; (*search for module*) WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; obj := obj1.next END ; IF obj = NIL THEN (*new module, search for alias*) obj := topScope.next; WHILE (obj # NIL) & ((obj.name # name) OR decl & ~obj.rdo) DO obj := obj.next END ; IF (obj # NIL) & obj.rdo & decl THEN ORS.Mark("mult def") ELSE (*insert new module*) NEW(mod); mod.class := Mod; mod.rdo := FALSE; mod.name := name; mod.orgname := orgname; mod.val := key; mod.lev := nofmod; INC(nofmod); mod.type := noType; mod.dsc := NIL; mod.next := NIL; obj1.next := mod; obj := mod END ELSIF decl THEN (*module already present, explicit import by declaration*) IF obj.rdo THEN ORS.Mark("mult def") ELSE ORS.Mark("invalid import order") END END ; RETURN obj END ThisModule; With that fix, the only remaining restriction in the PO 2013 compiler relative to Luca’s ‘oberonc’ compiler is the "invalid import order” restruction. And that one is also doable, but would be a tick more complex (merging of lists of type objects in mod.dsc). Worth the trouble? -ap - - - - > I agree. The above example works in oberonc <https://github.com/lboasso/oberonc> > (once you make use of the import M1 and global variable M0 since unused identifiers > will be an > error in oberonc). At this point I am more and more convinced that the > algorithm from* Griesemer R. On the Linearization of Graphs and Writing Symbol > File* is the best approach while still being relatively simple to implement. > This corner case and many more are handled and it removes the import order > limitation of Wirth's compiler. - - - - - > > On Thu, May 13, 2021 at 9:33 AM Andreas Pirklbauer < >> andreas_pirklbauer at yahoo.com> wrote: > > The following reports a “mult def” error in PO 2013 when compiling M2 > > > > MODULE M0; > > TYPE T0* = RECORD i: INTEGER END ; > > END M0. > > > > MODULE M1; > > IMPORT M0; > > TYPE T1* = RECORD (M0.T0) j: INTEGER END ; > > END M1. > > > > MODULE M2; > > IMPORT M1; (*re-imports M0.T0*) > > VAR M0: INTEGER; (* <--- "mult def” error message*) > > END M2. > > > > In PO2013 this error is reported because the symbol table headed > > by topScope *also* contains the re-imported module M0 (which is > > a bit unfortunate) -- but ORB.NewObj does not check that fact. > > > > I my mind, M2 should compile with no error message. i.e. hidden > > re-imports should be able to coexist with regular identifiers (since > > one cannot refer to re-imported objects by name anyway). > > > > Comments? > >

1 0

Should hidden re-imports be able to coexist with identifiers
by Andreas Pirklbauer 13 May '21

13 May '21

Hi Luca, Yes, you’re right, it works in oberonc of course.. because your compiler does not “merge” the module list with the list of identifiers as NW did in PO2013. You use module tables, just like Griesemer's algorithm. But now I just realized that the issue described below in fact has a trival fix also in PO 2013, namely to simply check (in ORB.NewObj and in ORB.thisObj) whether an object x in the topScope is in fact a re-imported module - and simply skip it if it is one. PS: A similar situation occurs, when hidden re-imports clash with alias names (they shouldn’t clash). With the change below it’s easy to fix to in ThisModule (see below). PS2: But the import order restriction would still remain. Andreas PROCEDURE NewObj*(VAR obj: Object; id: ORS.Ident; class: INTEGER); (*insert new Object with name id*) VAR new, x: Object; found: BOOLEAN; BEGIN x := topScope; found := FALSE; WHILE ~found & (x.next # NIL) DO IF ((x.next.class # Mod) OR x.next.rdo) & (x.next.name = id) THEN found := TRUE ELSE x := x.next END END ; IF x.next = NIL THEN NEW(new); new.name := id; new.class := class; new.next := NIL; new.rdo := FALSE; new.dsc := NIL; x.next := new; obj := new ELSE obj := x.next; ORS.Mark("mult def") END END NewObj; PROCEDURE thisObj*(): Object; VAR s, x: Object; found: BOOLEAN; BEGIN s := topScope; REPEAT x := s.next; found := FALSE; WHILE ~found & (x # NIL) DO IF ((x.class # Mod) OR x.rdo) & (x.name = ORS.id) THEN found := TRUE ELSE x := x.next END END ; s := s.dsc UNTIL (x # NIL) OR (s = NIL); RETURN x END thisObj; PROCEDURE thisimport*(mod: Object): Object; VAR obj: Object; BEGIN IF mod.rdo & (mod.name[0] # 0X) THEN obj := mod.dsc; WHILE (obj # NIL) & (obj.name # ORS.id) DO obj := obj.next END ELSE obj := NIL END ; RETURN obj END thisimport; PROCEDURE ThisModule(name, orgname: ORS.Ident; decl: BOOLEAN; key: LONGINT): Object; VAR mod: Module; obj, obj1: Object; BEGIN obj1 := topScope; obj := obj1.next; (*search for module*) WHILE (obj # NIL) & (obj(Module).orgname # orgname) DO obj1 := obj; obj := obj1.next END ; IF obj = NIL THEN (*new module, search for alias*) obj := topScope.next; WHILE (obj # NIL) & (obj.name # name) DO obj := obj.next END ; IF (obj # NIL) & decl & obj.rdo THEN ORS.Mark("mult def") ELSE (*insert new module*) NEW(mod); mod.class := Mod; mod.rdo := FALSE; mod.name := name; mod.orgname := orgname; mod.val := key; mod.lev := nofmod; INC(nofmod); mod.type := noType; mod.dsc := NIL; mod.next := NIL; obj1.next := mod; obj := mod END ELSIF decl THEN (*module already present, explicit import by declaration*) IF obj.rdo THEN ORS.Mark("mult def") ELSE ORS.Mark("invalid import order") END END ; RETURN obj END ThisModule; Andreas - - - - > I agree. The above example works in oberonc <https://github.com/lboasso/oberonc> > (once you make use of the import M1 and global variable M0 since unused identifiers > will be an > error in oberonc). At this point I am more and more convinced that the > algorithm from* Griesemer R. On the Linearization of Graphs and Writing Symbol > File* is the best approach while still being relatively simple to implement. > This corner case and many more are handled and it removes the import order > limitation of Wirth's compiler. - - - - - > > On Thu, May 13, 2021 at 9:33 AM Andreas Pirklbauer < >> andreas_pirklbauer at yahoo.com> wrote: > > The following reports a “mult def” error in PO 2013 when compiling M2 > > > > MODULE M0; > > TYPE T0* = RECORD i: INTEGER END ; > > END M0. > > > > MODULE M1; > > IMPORT M0; > > TYPE T1* = RECORD (M0.T0) j: INTEGER END ; > > END M1. > > > > MODULE M2; > > IMPORT M1; (*re-imports M0.T0*) > > VAR M0: INTEGER; (* <--- "mult def” error message*) > > END M2. > > > > In PO2013 this error is reported because the symbol table headed > > by topScope *also* contains the re-imported module M0 (which is > > a bit unfortunate) -- but ORB.NewObj does not check that fact. > > > > I my mind, M2 should compile with no error message. i.e. hidden > > re-imports should be able to coexist with regular identifiers (since > > one cannot refer to re-imported objects by name anyway). > > > > Comments? > >

1 0