<div dir="auto">A module M may be imported indirectly via more than a single import. There must be some merging of symbol file information of repeated parts of M for that case. If M is also imported directly I wonder what is the difference between merging the symbol file information of indirect imports versus merging the direct import. I have not studied the source code in detail but what I have seen is that it is simpler than previous versions. <div dir="auto"><br></div><div dir="auto">- Josef</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr"> <<a href="mailto:oberon-request@lists.inf.ethz.ch">oberon-request@lists.inf.ethz.ch</a>> schrieb am So., 3. März 2019, 00:46:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Oberon mailing list submissions to<br>
<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:oberon-request@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon-request@lists.inf.ethz.ch</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:oberon-owner@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon-owner@lists.inf.ethz.ch</a><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: Question on ORG.SaveRegs / ORG.RestoreRegs in the FPGA<br>
Oberon compiler (Tomas Kral)<br>
2. Question on ORG.SaveRegs / ORG.RestoreRegs in the FPGA Oberon<br>
compiler (Andreas Pirklbauer)<br>
3. Re: IMPORT Modules: why does order matter? (Richard Hable)<br>
4. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
5. Re: IMPORT Modules: why does order matter? (Skulski, Wojciech)<br>
6. Re: IMPORT Modules: why does order matter? (Till Oliver Knoll)<br>
7. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
8. Re: IMPORT Modules: why does order matter? (Skulski, Wojciech)<br>
9. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
10. Re: IMPORT Modules: why does order matter? (Till Oliver Knoll)<br>
11. Re: IMPORT Modules: why does order matter? (Michael Schierl)<br>
12. Re: IMPORT Modules: why does order matter? (Chris Burrows)<br>
13. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
14. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
15. IMPORT Modules: why does order matter? (Andreas Pirklbauer)<br>
16. Re: IMPORT Modules: why does order matter?<br>
(<a href="mailto:oberon@x.colbyrussell.com" target="_blank" rel="noreferrer">oberon@x.colbyrussell.com</a>)<br>
17. Re: IMPORT Modules: why does order matter? (Michael Schierl)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sat, 2 Mar 2019 12:04:03 +0100<br>
From: Tomas Kral <<a href="mailto:thomas.kral@email.cz" target="_blank" rel="noreferrer">thomas.kral@email.cz</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] Question on ORG.SaveRegs / ORG.RestoreRegs in<br>
the FPGA Oberon compiler<br>
Message-ID: <20190302120403.7523c6c5@raspberrypi><br>
Content-Type: text/plain; charset=US-ASCII<br>
<br>
On Mon, 18 Feb 2019 06:38:47 +0100<br>
Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>> wrote:<br>
<br>
> As a purely pedagogical addendum: A possible student exercise would<br>
> be to rewrite ORG assuming *no* procedure variables existed in the<br>
> language:<br>
<br>
<br>
Hi Andreas,<br>
<br>
Rarely do I receive your posts from the list, seems on account of my<br>
email client. <br>
<br>
Having read PO2013 Compiler Application, and Compiler construction<br>
books, still not feeling up to tinkering the compiler.<br>
<br>
I rather toy with the system, seems easier task, you may see my<br>
endeavours, some better then others :)<br>
<br>
Will delve into compiler books again and try to experiment a little.<br>
<br>
-- <br>
Tomas Kral <<a href="mailto:thomas.kral@email.cz" target="_blank" rel="noreferrer">thomas.kral@email.cz</a>><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sat, 2 Mar 2019 13:45:19 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] Question on ORG.SaveRegs / ORG.RestoreRegs in the<br>
FPGA Oberon compiler<br>
Message-ID: <<a href="mailto:90217C43-2F23-4291-B039-08A8A07F2BF0@yahoo.com" target="_blank" rel="noreferrer">90217C43-2F23-4291-B039-08A8A07F2BF0@yahoo.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
> > As a purely pedagogical addendum: A possible student exercise would be to<br>
> > rewrite ORG assuming *no* procedure variables existed in the language:<br>
> ><br>
> Having read PO2013 Compiler Application, and Compiler construction<br>
> books, still not feeling up to tinkering the compiler.<br>
<br>
Tomas,<br>
The question has been fully answered in the meantime. PS: In case you teach compiler construction,<br>
below is *one? possible sequencing of student exercises to gradually build up one's understanding.<br>
-ap<br>
<br>
---------------------------------------------------------------------------------------<br>
<br>
Step 0: Implement local/global procedure calls, assuming the language has *no* function procedures and *no* procedure variables<br>
<br>
PROCEDURE Call*(VAR x: Item);<br>
BEGIN Put3(BL, 7, (x.a DIV 4)-pc-1); RH := 0 (*see book ?Compiler Construction"*)<br>
END Call;<br>
<br>
Step 1: Add support for function procedures, but not procedure variables => result of a function procedure may be part of an expression (held in regs)<br>
<br>
PROCEDURE PrepCall*(VAR x: Item; VAR r: LONGINT);<br>
BEGIN (*x.type.form = ORB.Proc*) r := RH;<br>
IF RH > 0 THEN SaveRegs(RH); RH := 0 END<br>
END PrepCall;<br>
<br>
PROCEDURE Call*(VAR x: Item; r: LONGINT);<br>
BEGIN (*x.mode = ORB.Const & x.type.form = ORB.Proc*) Put3(BL, 7, (x.a DIV 4)-pc-1);<br>
IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0<br>
ELSE (*function*)<br>
IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;<br>
x.mode := Reg; x.r := r; RH := r+1<br>
END<br>
END Call;<br>
<br>
Step 2: Add support for *procedure variables* which are *not* de-referenced (as in ptr.handle) or selected (as in arr[3].handle, rec.fld.handle)<br>
<br>
PROCEDURE Call*(VAR x: Item; r: LONGINT);<br>
BEGIN (*x.type.form = ORB.Proc*)<br>
IF x.mode = ORB.Const THEN (*regular procedure*) Put3(BL, 7, (x.a DIV 4)-pc-1)<br>
ELSE (*procedure variable*) load(x); DEC(RH); (*e.g. x.mode = ORB.Var or ORB.Par*)<br>
IF check THEN Trap(EQ, 5) END ;<br>
Put3(BLR, 7, RH)<br>
END ;<br>
IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0<br>
ELSE (*function*)<br>
IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;<br>
x.mode := Reg; x.r := r; RH := r+1<br>
END<br>
END Call;<br>
<br>
Step 3: Allow *de-referencing* (ptr.handle) and *selecting* (array[0].handle, record.field.handle) of procedure variables<br>
<br>
PROCEDURE PrepCall*(VAR x: Item; VAR r: LONGINT);<br>
BEGIN (*x.type.form = ORB.Proc*)<br>
IF x.mode > ORB.Par THEN load(x) END ; (*if procedure variable has been dereferenced or selected => x.mode = RegI*)<br>
r := RH;<br>
IF RH > 0 THEN SaveRegs(RH); RH := 0 END<br>
END PrepCall;<br>
<br>
PROCEDURE Call*(VAR x: Item; r: LONGINT);<br>
BEGIN (*x.type.form = ORB.Proc*)<br>
IF x.mode = ORB.Const THEN (*regular procedure*) Put3(BL, 7, (x.a DIV 4)-pc-1)<br>
ELSE (*procedure variable*)<br>
IF x.mode <= ORB.Par THEN load(x); DEC(RH) (*x.mode = ORB.Var or ORB.Par*)<br>
ELSE Put2(Ldr, RH, SP, 0); Put1(Add, SP, SP, 4); DEC(r); DEC(frame, 4) (*x.mode = RegI or Reg}*)<br>
END ;<br>
IF check THEN Trap(EQ, 5) END ;<br>
Put3(BLR, 7, RH)<br>
END ;<br>
IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0<br>
ELSE (*function*)<br>
IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;<br>
x.mode := Reg; x.r := r; RH := r+1<br>
END<br>
END Call;<br>
<br>
Step 4: Allow imported procedures<br>
<br>
PROCEDURE Call*(VAR x: Item; r: LONGINT);<br>
BEGIN (*x.type.form = ORB.Proc*)<br>
IF x.mode = ORB.Const THEN (*regular procedure*)<br>
IF x.r >= 0 THEN Put3(BL, 7, (x.a DIV 4)-pc-1)<br>
ELSIF pc - fixorgP < 1000H THEN<br>
Put3(BL, 7, ((-x.r) (*mno*) * 100H + x.a (*exno*)) * 1000H + pc-fixorgP); fixorgP := pc-1<br>
ELSE ORS.Mark("fixup impossible")<br>
END<br>
ELSE (*procedure variable*)<br>
IF x.mode <= ORB.Par THEN load(x); DEC(RH)<br>
ELSE Put2(Ldr, RH, SP, 0); Put1(Add, SP, SP, 4); DEC(r); DEC(frame, 4)<br>
END ;<br>
IF check THEN Trap(EQ, 5) END ;<br>
Put3(BLR, 7, RH)<br>
END ;<br>
IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0<br>
ELSE (*function*)<br>
IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;<br>
x.mode := Reg; x.r := r; RH := r+1<br>
END<br>
END Call;<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Sat, 2 Mar 2019 14:20:57 +0100<br>
From: Richard Hable <<a href="mailto:informujo@aon.at" target="_blank" rel="noreferrer">informujo@aon.at</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:9e4286c1-303a-b72f-1cda-54a67006e2cb@aon.at" target="_blank" rel="noreferrer">9e4286c1-303a-b72f-1cda-54a67006e2cb@aon.at</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
On 02.03.19 05:22, Chris Burrows wrote:<br>
<br>
> M2 directly imports M0 but also indirectly imports M0 via M1. <br>
<br>
This doesn't make sense. Short identifier names are easy to get wrong?<br>
<br>
Do you mean, a module importing another module also has to explicitly<br>
import all modules referred by the imported module? That would be<br>
strange: as a user of a module I do not want to have to care about<br>
implementation details like its import list.<br>
<br>
Richard<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Sat, 2 Mar 2019 14:49:30 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:0AC2D396-4632-4CB3-BAC3-461D0A8B9213@yahoo.com" target="_blank" rel="noreferrer">0AC2D396-4632-4CB3-BAC3-461D0A8B9213@yahoo.com</a>><br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> Do you mean, a module importing another module<br>
> also has to explicitly import all modules referred<br>
> by the imported module? That would be strange.<br>
<br>
No! In general, this is not necessary, as the compiler<br>
handles indirect imports. One only needs to import<br>
an intermediate module, if the importing module<br>
refers to its exported objects. But *if* it is imported,<br>
all modules must be imported in the right order.<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190302/d42d093b/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190302/d42d093b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Sat, 2 Mar 2019 16:17:12 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu" target="_blank" rel="noreferrer">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID:<br>
<<a href="mailto:CY1PR07MB2634562F3BAE0C6224B1EA25FF770@CY1PR07MB2634.namprd07.prod.outlook.com" target="_blank" rel="noreferrer">CY1PR07MB2634562F3BAE0C6224B1EA25FF770@CY1PR07MB2634.namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> But *if* it is imported, all modules must be imported in the right order.<br>
<br>
Is there a tool which would analyze the import lists and order them in the required order? Or is the programmer forced to study the import diagrams from the book to arrange the lists by hand in the correct way?<br>
<br>
Wojtek<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Sat, 2 Mar 2019 17:40:48 +0100<br>
From: Till Oliver Knoll <<a href="mailto:till.oliver.knoll@gmail.com" target="_blank" rel="noreferrer">till.oliver.knoll@gmail.com</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:db52539e-0b64-a774-3398-2d96fceb3749@gmail.com" target="_blank" rel="noreferrer">db52539e-0b64-a774-3398-2d96fceb3749@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Am 02.03.19 um 05:22 schrieb Chris Burrows:<br>
>> -----Original Message-----<br>
>> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
>> Till Oliver Knoll<br>
>> Sent: Friday, 1 March 2019 7:44 AM<br>
>> To: Oberon Mailing List<br>
>> Subject: [Oberon] IMPORT Modules: why does order matter?<br>
>><br>
>> Hello,<br>
>><br>
>> It seems that with the Project Oberon 2013 compiler the order of<br>
>> imported modules seems to matter now ...<br>
> An example of a situation where it does matter when using the Project Oberon compiler:<br>
> <br>
> M0 declares a structured type T0<br>
> M1 exports variable x1: M0.T0<br>
> M2 declares variable x2: M0 and references M1.x1<br>
> <br>
> M2 directly imports M0 but also indirectly imports M0 via M1. In that case, in M2's import list should be IMPORT M0, M1.<br>
<br>
Hmmm, I kind of see at what you're getting (I believe you meant "M2<br>
directly imports *M1*" and I guess you meant "x2: M0.*T0" (as a module<br>
itself cannot be a type ;)), however I am not quite sure if it makes<br>
sense to me yet.<br>
<br>
So here is what I think your example was, for M2:<br>
<br>
MODULE M2;<br>
<br>
IMPORT M0, M1;<br>
<br>
VAR<br>
x2: M0.T0; (* For this we need to import M0, sure *)<br>
<br>
BEGIN<br>
x2 := M1.x1; (* We access M1 which needs to be imported, too *)<br>
<br>
...<br>
<br>
<br>
<br>
As we are using explicit types and variables from two different modules<br>
M0 and M1 it is clear to me that we need to import them both. And I<br>
understand what you're saying, that since there is a dependency from M1<br>
on M0, we (M2) also "need to import M0 first (before M1)".<br>
<br>
But still I don't understand the exact *why*, except that the compiler<br>
has become more "lazy" (well, "simpler") than, say, in OberonV4 (or<br>
Oberon90 - not sure anymore which we used last at the ETH).<br>
<br>
Because the import order definitively did *not* matter in earlier<br>
versions of Oberon (that I know).<br>
<br>
<br>
Thanks,<br>
Oliver<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Sat, 2 Mar 2019 19:41:15 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:09A16835-E56B-4830-9B10-6C20508F9D9D@yahoo.com" target="_blank" rel="noreferrer">09A16835-E56B-4830-9B10-6C20508F9D9D@yahoo.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
> Or is the programmer forced to study the import diagrams from the book to arrange the<br>
> lists by hand in the correct way?<br>
<br>
Just build the list *once*, e.g. for FPGA Oberon:<br>
<br>
Kernel, FileDir, Files, Modules,<br>
Input, Display, Viewers,<br>
Fonts, Texts, Oberon,<br>
MenuViewers, TextFrames,<br>
System, Edit, Tools<br>
ORS, ORB, ORG, ORP, ORTool<br>
Graphics, GraphicFrames, Draw,<br>
GraphTool, MacroTool, <br>
Curves, Sierpinski, Hilbert, Stars, Rectangles, Checkers<br>
...<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Sat, 2 Mar 2019 18:50:57 +0000<br>
From: "Skulski, Wojciech" <<a href="mailto:skulski@pas.rochester.edu" target="_blank" rel="noreferrer">skulski@pas.rochester.edu</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID:<br>
<<a href="mailto:CY1PR07MB2634E75EC8909CADBD54C0DCFF770@CY1PR07MB2634.namprd07.prod.outlook.com" target="_blank" rel="noreferrer">CY1PR07MB2634E75EC8909CADBD54C0DCFF770@CY1PR07MB2634.namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Andreas:<br>
<br>
imagine I write my own module Acquire which is reading some FPGA registers with direct addressing the FPGA, and writes the number to the system log via Out.Int(value). The only import would be Out. Do I need to import all the other stuff which you listed below?<br>
<br>
In previous Oberons, as well as in BlackBox, the complete import list was not needed. Is it needed now? If so, can this new feature be fixed as it does not seem friendly?<br>
<br>
Wojtek<br>
________________________________________<br>
From: Oberon [<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon-bounces@lists.inf.ethz.ch</a>] on behalf of Andreas Pirklbauer [<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>]<br>
Sent: Saturday, March 2, 2019 1:41 PM<br>
To: ETH Oberon and related systems<br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
<br>
> Or is the programmer forced to study the import diagrams from the book to arrange the<br>
> lists by hand in the correct way?<br>
<br>
Just build the list *once*, e.g. for FPGA Oberon:<br>
<br>
Kernel, FileDir, Files, Modules,<br>
Input, Display, Viewers,<br>
Fonts, Texts, Oberon,<br>
MenuViewers, TextFrames,<br>
System, Edit, Tools<br>
ORS, ORB, ORG, ORP, ORTool<br>
Graphics, GraphicFrames, Draw,<br>
GraphTool, MacroTool,<br>
Curves, Sierpinski, Hilbert, Stars, Rectangles, Checkers<br>
...<br>
<br>
<br>
<br>
<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=CBGseygccK22G5EVW_cVQMxoTScL1oMi5by75dp_wuA&s=0rJum3W4lLtpwfOqasMOhrlzJjyQQVBZmqDsfGbfj8M&e=" rel="noreferrer noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.inf.ethz.ch_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=CBGseygccK22G5EVW_cVQMxoTScL1oMi5by75dp_wuA&s=0rJum3W4lLtpwfOqasMOhrlzJjyQQVBZmqDsfGbfj8M&e=</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Sat, 2 Mar 2019 20:06:03 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:40CCF3D3-E5A4-48FD-A988-6EFBA6477AB4@yahoo.com" target="_blank" rel="noreferrer">40CCF3D3-E5A4-48FD-A988-6EFBA6477AB4@yahoo.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
> imagine I write my own module Acquire which is reading some FPGA registers with<br>
> direct addressing the FPGA, and writes the number to the system log via Out.Int(value).<br>
> The only import would be Out. Do I need to import all the other stuff which you listed below?<br>
<br>
No, you don?t. You only need to import those modules M, whose exported constants, types,<br>
variables or procedures you reference in your module (by name), e.g. when you call M.P.<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Sat, 2 Mar 2019 22:18:12 +0100<br>
From: Till Oliver Knoll <<a href="mailto:till.oliver.knoll@gmail.com" target="_blank" rel="noreferrer">till.oliver.knoll@gmail.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:50C2B27A-101B-46F4-A12C-1C23CE6CC8A7@gmail.com" target="_blank" rel="noreferrer">50C2B27A-101B-46F4-A12C-1C23CE6CC8A7@gmail.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
> Am 02.03.2019 um 19:50 schrieb Skulski, Wojciech <<a href="mailto:skulski@pas.rochester.edu" target="_blank" rel="noreferrer">skulski@pas.rochester.edu</a>>:<br>
> <br>
> Andreas:<br>
> <br>
> imagine I write my own module Acquire which is reading some FPGA registers with direct addressing the FPGA, and writes the number to the system log via Out.Int(value). The only import would be Out. Do I need to import all the other stuff which you listed below?<br>
> <br>
> In previous Oberons, as well as in BlackBox, the complete import list was not needed. Is it needed now? If so, can this new feature be fixed as it does not seem friendly?<br>
<br>
I can answer this :)<br>
<br>
No, you just need to import the modules which your modules directly uses, nothing more.<br>
<br>
But if you import several modules, say Display and Oberon, then Display needs (apparently newly) to come before Oberon, as the module directly or indirectly imports Display - according to the module hierarchy.<br>
<br>
To be clear: I am using ?Oberon Core?, as available in the Mac App Store. For all I know that is based on Project Oberon 2013, and running on some RISC emulator (the RISC CPU designed for the FPGA mentioned in Niklaus Wirth?s revised Oberon book).<br>
<br>
At least my version of Oberon is missing now the Out module. That?s because ?Oberon Core? is a ?bare minimum? distribution (the company offering it also has a commercial offering), or the module Out has really been deemed redundant and hence been removed in ?Project Oberon 2013? (as you can use a Texts writer and append the Text to Oberon.Log - which is what I think module Out was doing in the end.)<br>
<br>
I am only mentioning this because if your ?FPGA Oberon? still has module Out then you might have a different compiler, too, and the import order might not even matter there.<br>
<br>
For example the ?Oberon Core? / Project Oberon 2013 (?) compiler I use does not even have the ?numerical case? statement implemented (which is defined for the language ?Oberon 07?). So it might as well be that the compiler that I am using is not ?fully feature complete?, and maybe someone took a ?shortcut? in validating the IMPORTs (because from a compiler point of view it might be easier to parse/validate ?if they are in order? - unfortunately I have not yet read Wirth?s compiler book, shame on me ;)).<br>
<br>
So the question I still have (out of pure curiosity):<br>
<br>
* Do others actually confirm that they get the same ?wrong import order? compiler error (really at the line of the IMPORT, as soon as the first ?out of order? module is found)?<br>
<br>
* Is there a real technical (compiler) reason behind this, e.g. does it speed up compilation, greatly simplifies parsing or otherwise is just advanteous?<br>
<br>
* Or is it really to ?force? the developer in the sense of ?Hey! Know your modules!?<br>
<br>
Because if the later I don?t think that such a ?validation? helps to write better code. As it would not ?scale?. Think of importing 3rd party modules. Think of if there would be dozens - well, hundreds ;) - of modules to choose from. And you are supposed to know all their dependencies?<br>
<br>
Don?t get me wrong, I am not trying to critisise, I am genuinely interested in the design decision here. In all simplifications done in Oberon07/2013 I do see the beauty - but not so much here yet.<br>
<br>
Cheers,<br>
Oliver<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Sat, 2 Mar 2019 23:23:30 +0100<br>
From: Michael Schierl <<a href="mailto:schierlm@gmx.de" target="_blank" rel="noreferrer">schierlm@gmx.de</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:e09e5c43-0c59-02bf-9bee-0fa3949cc39e@gmx.de" target="_blank" rel="noreferrer">e09e5c43-0c59-02bf-9bee-0fa3949cc39e@gmx.de</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hello Till,<br>
<br>
<br>
Am 02.03.2019 um 22:18 schrieb Till Oliver Knoll:<br>
<br>
> At least my version of Oberon is missing now the Out module. That?s<br>
> because ?Oberon Core? is a ?bare minimum? distribution (the company<br>
> offering it also has a commercial offering),<br>
<br>
I believe the differences in the commercial offering are only the<br>
supported features of the emulator (like different virtual RAM sizes or<br>
network support or HostFS support (to access files on the host from<br>
within the VM)), not in the source of the Oberon system that is running<br>
inside. But since I do not own a Mac and have therefore neither used<br>
"Oberon Core" nor "Oberon Workstation", I cannot tell for sure.<br>
<br>
> or the module Out has<br>
> really been deemed redundant and hence been removed in ?Project<br>
> Oberon 2013? (as you can use a Texts writer and append the Text to<br>
> Oberon.Log - which is what I think module Out was doing in the end.)<br>
<br>
There is no Module "Out" in Project Oberon 2013. See<br>
<<a href="http://www.projectoberon.com" rel="noreferrer noreferrer" target="_blank">www.projectoberon.com</a>> or<br>
<<a href="https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html" rel="noreferrer noreferrer" target="_blank">https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html</a>> for<br>
all included modules.<br>
<br>
I have made a webpage with syntax highlighted annotated HTML files for<br>
the Project Oberon 2013 source files, at<br>
<<a href="https://schierlm.github.io/OberonXref/ProjectOberon2013/" rel="noreferrer noreferrer" target="_blank">https://schierlm.github.io/OberonXref/ProjectOberon2013/</a>>. There you<br>
can also see that there is no "Out" module.<br>
<br>
> So the question I still have (out of pure curiosity):<br>
> <br>
> * Do others actually confirm that they get the same ?wrong import<br>
> order? compiler error (really at the line of the IMPORT, as soon as<br>
> the first ?out of order? module is found)?<br>
<br>
The error message is "invalid import order", but it does exist in<br>
Project Oberon 2013:<br>
<br>
<<a href="https://schierlm.github.io/OberonXref/ProjectOberon2013/ORB.html#L_142" rel="noreferrer noreferrer" target="_blank">https://schierlm.github.io/OberonXref/ProjectOberon2013/ORB.html#L_142</a>><br>
<br>
Numerical case statements are not implemented there either:<br>
<br>
<<a href="https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#L_579" rel="noreferrer noreferrer" target="_blank">https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#L_579</a>><br>
<br>
> * Is there a real technical (compiler) reason behind this, e.g. does<br>
> it speed up compilation, greatly simplifies parsing or otherwise is<br>
> just advanteous?<br>
<br>
Not 100% sure, but I assume it just makes the compiler slightly simpler<br>
as it can (explicitly) import a module and (implicitly) all its<br>
dependencies while parsing the actual IMPORT statement instead of having<br>
to check the dependencies against the modules stated later to make sure<br>
that the dependencies get imported as explicit imports in the right order.<br>
<br>
> And you are supposed to know all their dependencies?<br>
<br>
In my experience, trial and error is "fast enough", especially since<br>
when you get the error, the cursor is on the module that is imported too<br>
late, so you just successively move it further to the beginning of the<br>
line until it is accepted. But I am only toying with the Oberon system,<br>
and do not use it for anything critical (and the number of compile<br>
errors because of a missing colon in := is vastly above the number of<br>
import order errors), so your mileage may vary.<br>
<br>
> I am only mentioning this because if your ?FPGA Oberon? still has<br>
> module Out then you might have a different compiler, too, and the<br>
> import order might not even matter there.<br>
<br>
<br>
I believe that in Experimental Oberon, import order does not matter, and<br>
it also supports both Numerical case statements and the Out module (as<br>
well as procedure forward declarations and some other goodies that make<br>
your life easier at the cost of making the system more complex). But<br>
Andreas can comment on that one better than me.<br>
<br>
<br>
Regards,<br>
<br>
<br>
Michael<br>
<br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Sun, 3 Mar 2019 09:37:50 +1030<br>
From: "Chris Burrows" <<a href="mailto:chris@cfbsoftware.com" target="_blank" rel="noreferrer">chris@cfbsoftware.com</a>><br>
To: "'ETH Oberon and related systems'" <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <000901d4d14c$c2e53d30$48afb790$@<a href="http://cfbsoftware.com" rel="noreferrer noreferrer" target="_blank">cfbsoftware.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
> Till Oliver Knoll<br>
> Sent: Sunday, 3 March 2019 7:48 AM<br>
> To: ETH Oberon and related systems<br>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
> <br>
> For example the Oberon Core / Project Oberon 2013 (?) compiler I<br>
> use does not even have the numerical case statement implemented<br>
> (which is defined for the language Oberon 07 ). <br>
<br>
That is consistent with Wirth's Project Oberon compiler. We have added numeric case in our Oberon-07 implementation (Astrobe for RISC5). To do this efficiently it was necessary to implement a variant of the Branch Conditional instruction in the RISC5 processor. For more information see:<br>
<br>
"Numeric CASE vs IF THEN ELSE performance"<br>
<br>
<a href="http://www.astrobe.com/forum/viewtopic.php?f=13&t=552" rel="noreferrer noreferrer" target="_blank">http://www.astrobe.com/forum/viewtopic.php?f=13&t=552</a><br>
<br>
<br>
> So it might as well<br>
> be that the compiler that I am using is not fully feature complete ,<br>
> and maybe someone took a shortcut in validating the IMPORTs<br>
> (because from a compiler point of view it might be easier to<br>
> parse/validate if they are in order - unfortunately I have not yet<br>
> read Wirth s compiler book, shame on me ;)).<br>
> <br>
> So the question I still have (out of pure curiosity):<br>
> <br>
> * Do others actually confirm that they get the same wrong import<br>
> order compiler error (really at the line of the IMPORT, as soon as<br>
> the first out of order module is found)?<br>
> <br>
> * Is there a real technical (compiler) reason behind this, e.g. does<br>
> it speed up compilation, greatly simplifies parsing or otherwise is<br>
> just advanteous?<br>
> <br>
> * Or is it really to force the developer in the sense of Hey! Know<br>
> your modules!<br>
> <br>
<br>
Yes - I believe there are elements in all of the above that led to this implementation restriction.<br>
<br>
>From the technical point of view we have only just introduced this restriction ourselves in v7.0 of the Atrobe ARM Cortex-Mx compilers to help resolve some obscure problems reported by a user which were related to direct / indirect imports. When aliased imports are involved as well it can get very tricky. <br>
<br>
The question of forcing the developer to 'know your modules' is more subjective. As a devil's advocate I would ask the question: <br>
<br>
Ideally, in what order should the modules be listed on an IMPORT list?<br>
<br>
1. Alphabetic? - useful if they are long lists and you want to know if you've missed one.<br>
<br>
2. Bottom-up? - useful if you want to know in what order you should recompile them if necessary. Also useful to get an idea what you might break if you modify any of the interfaces (you only need to potentially worry about the modules that come after the one you are modifying). <br>
<br>
3. Random? - Useful if you are a contract programmer and ongoing maintenance of your code wasn't specified in your contract later. Also useful if you don't have a clue about what you are doing. ;-)<br>
<br>
4. Something else?<br>
<br>
Having spent much time over many decades maintaining code bases with the source code of thousands of modules not written by me I would have been really grateful if the development system had encouraged explicit module references and some sort of ordering of imports rather than leaving it up to the programmer. A development manager should always keep in mind that in the life-cycle of software typically 10-20% of the costs are incurred by the original development whereas 80-90% of the costs are incurred maintaining it. When choosing development tools they would be wise to consider how well the tool helps to encourage good programming practices and lessen the need for themselves to 'herd cats'.<br>
<br>
Having said all that, I can see this restriction might cause some head-scratching if you are trying to port a large application from an older version of Oberon. However, (shameless plug coming) it is less of a problem in Astrobe because it includes a build tool to ensure that all imported modules are recompiled in the correct order. The output log of this makes it very obvious how to order the modules on an import list if the error should arise. And to answer your next question - no we don't have a version that runs on Apple devices :(<br>
<br>
Regards,<br>
Chris Burrows<br>
CFB Software<br>
<a href="http://www.astrobe.com/RISC5" rel="noreferrer noreferrer" target="_blank">http://www.astrobe.com/RISC5</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Sun, 3 Mar 2019 00:13:30 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:35CE28C4-F16B-428A-89F1-7FE39020499C@yahoo.com" target="_blank" rel="noreferrer">35CE28C4-F16B-428A-89F1-7FE39020499C@yahoo.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
> I believe that in Experimental Oberon, import order does not matter.<br>
<br>
The import order *does* matter in Experimental Oberon, just like in FPGA Oberon. This was a deliberate design decision. If one wanted to allow imports to be declared in *any* order in the source text, it could (relatively) easily be implemented. The cost is <50 lines of additional source lines of code in module ORB. For sample implementations, see the Ceres-Oberon sources or Ref [1] below. Both essentially maintain a "module table" when parsing the import statement.<br>
<br>
But the question is whether one *should* allow imports to be declared in *any* order. This could be endlessly debated... There are arguments for and against it; e.g. ?for" = imposing the import order does not scale to large numbers of modules, ?against? = a tool could easily be provided that performs a topological search of the directed acyclic graph of the module hierarchy (this was a popular student exercise at ETH). The question simply is who orders the list - the compiler, a separate tool, or the programmer (manually).<br>
<br>
<br>
[1] Griesemer R. On the Linearization of Graphs and Writing Symbol Files. Computersysteme ETH Z?rich, Technical Report No. 156a (1991), see <a href="https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68903/eth-3310-01.pdf" rel="noreferrer noreferrer" target="_blank">https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68903/eth-3310-01.pdf</a><br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Sun, 3 Mar 2019 00:29:51 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:62A81155-DF56-441C-9416-CD7E8BCF620C@yahoo.com" target="_blank" rel="noreferrer">62A81155-DF56-441C-9416-CD7E8BCF620C@yahoo.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
> I believe that in Experimental Oberon ? also supports both Numerical case statements.<br>
<br>
This is correct, see [1] and [2] for more information. But *unlike* the Astrobe for RISC implementation (see <a href="http://www.astrobe.com" rel="noreferrer noreferrer" target="_blank">www.astrobe.com</a>), the Experimental Oberon version does *not* make use of the modified Branch Conditional (BC) instruction that is used in the Astrobe compiler (the BC instruction of the original RISC is of the form B,cond [Rn], whereas Astrobe?s adds one of the form B,cond PC, [Rn], where the target of the branch is computed by adding the contents of a register to the current program counter - this change reduces the average overhead of any selection in a CASE statement from about 9 or 10 down to 6 instructions, making the numeric CASE statement considerably more efficient).<br>
<br>
Should that modified BC instruction (B,cond PC, [Rn]) become part of the ?official? RISC architecture one day (as published on <a href="http://www.projectoberon.com" rel="noreferrer noreferrer" target="_blank">www.projectoberon.com</a>), Experimental Oberon would switch over and also make use of it.<br>
<br>
-ap<br>
<br>
<br>
[1] <a href="http://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Documentation/Enhanced-FPGA-Oberon07-compiler.pdf" rel="noreferrer noreferrer" target="_blank">http://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Documentation/Enhanced-FPGA-Oberon07-compiler.pdf</a><br>
[2] <a href="http://github.com/andreaspirklbauer/Oberon-numeric-case-statement" rel="noreferrer noreferrer" target="_blank">http://github.com/andreaspirklbauer/Oberon-numeric-case-statement</a><br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Sun, 3 Mar 2019 00:39:13 +0100<br>
From: Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>><br>
Subject: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:0125A3F1-A99C-435E-90F4-83D927B5473B@yahoo.com" target="_blank" rel="noreferrer">0125A3F1-A99C-435E-90F4-83D927B5473B@yahoo.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
> Having said all that, I can see this restriction might cause some head-scratching if you are trying to<br>
> port a large application from an older version of Oberon. However, (shameless plug coming) it is less<br>
> of a problem in Astrobe because it includes a build tool to ensure that all imported modules are<br>
> recompiled in the correct order. The output log of this makes it very obvious how to order the<br>
> modules on an import list if the error should arise.<br>
<br>
Such a tool would no doubt be beneficial to FPGA Oberon as well. Except that.. where<br>
are those thousands of FPGA Oberon modules? ;-)<br>
<br>
> And to answer your next question - no we don't have a version that runs on Apple devices :(<br>
<br>
Will there be one one day? You?d have one more user..<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Sat, 2 Mar 2019 17:42:03 -0600<br>
From: <a href="mailto:oberon@x.colbyrussell.com" target="_blank" rel="noreferrer">oberon@x.colbyrussell.com</a><br>
To: ETH Oberon and related systems <<a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a>>, Andreas<br>
Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com" target="_blank" rel="noreferrer">andreas_pirklbauer@yahoo.com</a>><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:a60b5025-b6f0-a5c6-e881-fe5ac7df545f@colbyrussell.com" target="_blank" rel="noreferrer">a60b5025-b6f0-a5c6-e881-fe5ac7df545f@colbyrussell.com</a>><br>
Content-Type: text/plain; charset=utf-8; format=flowed<br>
<br>
On 3/2/19 5:13 PM, Andreas Pirklbauer wrote:<br>
> If one wanted to allow imports to be declared in *any* order [...]<br>
> cost is <50 lines of additional source lines of code<br>
<br>
This topic seems to have taken way too long to get to the answer, and it<br>
looks like we're still not there.<br>
<br>
*Why* does import order matter?<br>
<br>
In other words, what would these 50 additional lines of code need to<br>
ensure?<br>
<br>
In other other words, what problem arises in the absence of the<br>
conditional branch in the compiler that results in this error being<br>
printed?<br>
<br>
-- <br>
Colby Russell<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 17<br>
Date: Sun, 3 Mar 2019 00:45:50 +0100<br>
From: Michael Schierl <<a href="mailto:schierlm@gmx.de" target="_blank" rel="noreferrer">schierlm@gmx.de</a>><br>
To: <a href="mailto:oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">oberon@lists.inf.ethz.ch</a><br>
Subject: Re: [Oberon] IMPORT Modules: why does order matter?<br>
Message-ID: <<a href="mailto:ca1f6ac9-a5bb-ee58-5bb3-0980fccd407b@gmx.de" target="_blank" rel="noreferrer">ca1f6ac9-a5bb-ee58-5bb3-0980fccd407b@gmx.de</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hello,<br>
<br>
Am 03.03.2019 um 00:13 schrieb Andreas Pirklbauer:<br>
> I believe that in Experimental Oberon, import order does not matter.<br>
> <br>
> The import order *does* matter in Experimental Oberon, just like in<br>
> FPGA Oberon. This was a deliberate design decision.<br>
<br>
Removing forward references was also a deliberate design decision.<br>
<br>
On the other hand, the Experimental Oberon compiler backports Oberon-2<br>
features to make porting code from Oberon-2 easier (To be honest, it is<br>
still on my TODO list to pick a "random" module from Native Oberon and<br>
try how many changes are really required to make it compile in<br>
Experimental Oberon). That's why I assumed import order restrictions<br>
were also "eliminated" there.<br>
<br>
<br>
But perhaps I should not draw such conclusions without trying it :-)<br>
<br>
<br>
Another example: Experimental Oberon also adds some safety features<br>
(e.g. with respect to module unloading), yet it does not prevent access<br>
to uninitialized local (pointer) variables. There is a simple to<br>
implement solution for that (but that comes with a runtime performance<br>
penalty):<br>
<<a href="https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/initialize-local-variables.patch" rel="noreferrer noreferrer" target="_blank">https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/initialize-local-variables.patch</a>>.<br>
<br>
Solutions without runtime performance penalty would make the compiler<br>
more complex as it has to track that variables are initialized before<br>
they are used (with the ambiguity whether a variable that is passed via<br>
VAR to another procedure has to be initialized before or not; similar to<br>
<ref> vs <out> in C#).<br>
<br>
<br>
Regards,<br>
<br>
<br>
Michael<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
<br>
------------------------------<br>
<br>
End of Oberon Digest, Vol 178, Issue 3<br>
**************************************<br>
</blockquote></div>