[Oberon] IMPORT Modules: why does order matter?
Josef Templ
josef.templ at gmail.com
Sun Mar 3 15:01:09 CET 2019
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.
- Josef
<oberon-request at lists.inf.ethz.ch> schrieb am So., 3. März 2019, 00:46:
> Send Oberon mailing list submissions to
> oberon at lists.inf.ethz.ch
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> or, via email, send a message with subject or body 'help' to
> oberon-request at lists.inf.ethz.ch
>
> You can reach the person managing the list at
> oberon-owner at lists.inf.ethz.ch
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Oberon digest..."
>
>
> Today's Topics:
>
> 1. Re: Question on ORG.SaveRegs / ORG.RestoreRegs in the FPGA
> Oberon compiler (Tomas Kral)
> 2. Question on ORG.SaveRegs / ORG.RestoreRegs in the FPGA Oberon
> compiler (Andreas Pirklbauer)
> 3. Re: IMPORT Modules: why does order matter? (Richard Hable)
> 4. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 5. Re: IMPORT Modules: why does order matter? (Skulski, Wojciech)
> 6. Re: IMPORT Modules: why does order matter? (Till Oliver Knoll)
> 7. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 8. Re: IMPORT Modules: why does order matter? (Skulski, Wojciech)
> 9. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 10. Re: IMPORT Modules: why does order matter? (Till Oliver Knoll)
> 11. Re: IMPORT Modules: why does order matter? (Michael Schierl)
> 12. Re: IMPORT Modules: why does order matter? (Chris Burrows)
> 13. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 14. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 15. IMPORT Modules: why does order matter? (Andreas Pirklbauer)
> 16. Re: IMPORT Modules: why does order matter?
> (oberon at x.colbyrussell.com)
> 17. Re: IMPORT Modules: why does order matter? (Michael Schierl)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 2 Mar 2019 12:04:03 +0100
> From: Tomas Kral <thomas.kral at email.cz>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] Question on ORG.SaveRegs / ORG.RestoreRegs in
> the FPGA Oberon compiler
> Message-ID: <20190302120403.7523c6c5 at raspberrypi>
> Content-Type: text/plain; charset=US-ASCII
>
> On Mon, 18 Feb 2019 06:38:47 +0100
> Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote:
>
> > As a purely pedagogical addendum: A possible student exercise would
> > be to rewrite ORG assuming *no* procedure variables existed in the
> > language:
>
>
> Hi Andreas,
>
> Rarely do I receive your posts from the list, seems on account of my
> email client.
>
> Having read PO2013 Compiler Application, and Compiler construction
> books, still not feeling up to tinkering the compiler.
>
> I rather toy with the system, seems easier task, you may see my
> endeavours, some better then others :)
>
> Will delve into compiler books again and try to experiment a little.
>
> --
> Tomas Kral <thomas.kral at email.cz>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 2 Mar 2019 13:45:19 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] Question on ORG.SaveRegs / ORG.RestoreRegs in the
> FPGA Oberon compiler
> Message-ID: <90217C43-2F23-4291-B039-08A8A07F2BF0 at yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> > > As a purely pedagogical addendum: A possible student exercise would
> be to
> > > rewrite ORG assuming *no* procedure variables existed in the
> language:
> > >
> > Having read PO2013 Compiler Application, and Compiler construction
> > books, still not feeling up to tinkering the compiler.
>
> Tomas,
> The question has been fully answered in the meantime. PS: In case you
> teach compiler construction,
> below is *one? possible sequencing of student exercises to gradually build
> up one's understanding.
> -ap
>
>
> ---------------------------------------------------------------------------------------
>
> Step 0: Implement local/global procedure calls, assuming the language has
> *no* function procedures and *no* procedure variables
>
> PROCEDURE Call*(VAR x: Item);
> BEGIN Put3(BL, 7, (x.a DIV 4)-pc-1); RH := 0
> (*see book ?Compiler Construction"*)
> END Call;
>
> 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)
>
> PROCEDURE PrepCall*(VAR x: Item; VAR r: LONGINT);
> BEGIN (*x.type.form = ORB.Proc*) r := RH;
> IF RH > 0 THEN SaveRegs(RH); RH := 0 END
> END PrepCall;
>
> PROCEDURE Call*(VAR x: Item; r: LONGINT);
> BEGIN (*x.mode = ORB.Const & x.type.form = ORB.Proc*) Put3(BL, 7, (x.a
> DIV 4)-pc-1);
> IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0
> ELSE (*function*)
> IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;
> x.mode := Reg; x.r := r; RH := r+1
> END
> END Call;
>
> 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)
>
> PROCEDURE Call*(VAR x: Item; r: LONGINT);
> BEGIN (*x.type.form = ORB.Proc*)
> IF x.mode = ORB.Const THEN (*regular procedure*) Put3(BL, 7, (x.a DIV
> 4)-pc-1)
> ELSE (*procedure variable*) load(x); DEC(RH);
> (*e.g. x.mode = ORB.Var or ORB.Par*)
> IF check THEN Trap(EQ, 5) END ;
> Put3(BLR, 7, RH)
> END ;
> IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0
> ELSE (*function*)
> IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;
> x.mode := Reg; x.r := r; RH := r+1
> END
> END Call;
>
> Step 3: Allow *de-referencing* (ptr.handle) and *selecting*
> (array[0].handle, record.field.handle) of procedure variables
>
> PROCEDURE PrepCall*(VAR x: Item; VAR r: LONGINT);
> BEGIN (*x.type.form = ORB.Proc*)
> IF x.mode > ORB.Par THEN load(x) END ; (*if procedure
> variable has been dereferenced or selected => x.mode = RegI*)
> r := RH;
> IF RH > 0 THEN SaveRegs(RH); RH := 0 END
> END PrepCall;
>
> PROCEDURE Call*(VAR x: Item; r: LONGINT);
> BEGIN (*x.type.form = ORB.Proc*)
> IF x.mode = ORB.Const THEN (*regular procedure*) Put3(BL, 7, (x.a DIV
> 4)-pc-1)
> ELSE (*procedure variable*)
> IF x.mode <= ORB.Par THEN load(x); DEC(RH)
> (*x.mode = ORB.Var or ORB.Par*)
> ELSE Put2(Ldr, RH, SP, 0); Put1(Add, SP, SP, 4); DEC(r); DEC(frame,
> 4) (*x.mode = RegI or Reg}*)
> END ;
> IF check THEN Trap(EQ, 5) END ;
> Put3(BLR, 7, RH)
> END ;
> IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0
> ELSE (*function*)
> IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;
> x.mode := Reg; x.r := r; RH := r+1
> END
> END Call;
>
> Step 4: Allow imported procedures
>
> PROCEDURE Call*(VAR x: Item; r: LONGINT);
> BEGIN (*x.type.form = ORB.Proc*)
> IF x.mode = ORB.Const THEN (*regular procedure*)
> IF x.r >= 0 THEN Put3(BL, 7, (x.a DIV 4)-pc-1)
> ELSIF pc - fixorgP < 1000H THEN
> Put3(BL, 7, ((-x.r) (*mno*) * 100H + x.a (*exno*)) * 1000H +
> pc-fixorgP); fixorgP := pc-1
> ELSE ORS.Mark("fixup impossible")
> END
> ELSE (*procedure variable*)
> IF x.mode <= ORB.Par THEN load(x); DEC(RH)
> ELSE Put2(Ldr, RH, SP, 0); Put1(Add, SP, SP, 4); DEC(r); DEC(frame,
> 4)
> END ;
> IF check THEN Trap(EQ, 5) END ;
> Put3(BLR, 7, RH)
> END ;
> IF x.type.base.form = ORB.NoTyp THEN (*procedure*) RH := 0
> ELSE (*function*)
> IF r > 0 THEN Put0(Mov, r, 0, 0); RestoreRegs(r) END ;
> x.mode := Reg; x.r := r; RH := r+1
> END
> END Call;
>
> ------------------------------
>
> Message: 3
> Date: Sat, 2 Mar 2019 14:20:57 +0100
> From: Richard Hable <informujo at aon.at>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <9e4286c1-303a-b72f-1cda-54a67006e2cb at aon.at>
> Content-Type: text/plain; charset=utf-8
>
> On 02.03.19 05:22, Chris Burrows wrote:
>
> > M2 directly imports M0 but also indirectly imports M0 via M1.
>
> This doesn't make sense. Short identifier names are easy to get wrong?
>
> Do you mean, a module importing another module also has to explicitly
> import all modules referred by the imported module? That would be
> strange: as a user of a module I do not want to have to care about
> implementation details like its import list.
>
> Richard
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 2 Mar 2019 14:49:30 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: oberon at lists.inf.ethz.ch
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <0AC2D396-4632-4CB3-BAC3-461D0A8B9213 at yahoo.com>
> Content-Type: text/plain; charset="us-ascii"
>
> > Do you mean, a module importing another module
> > also has to explicitly import all modules referred
> > by the imported module? That would be strange.
>
> No! In general, this is not necessary, as the compiler
> handles indirect imports. One only needs to import
> an intermediate module, if the importing module
> refers to its exported objects. But *if* it is imported,
> all modules must be imported in the right order.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190302/d42d093b/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Sat, 2 Mar 2019 16:17:12 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID:
> <
> CY1PR07MB2634562F3BAE0C6224B1EA25FF770 at CY1PR07MB2634.namprd07.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> > But *if* it is imported, all modules must be imported in the right order.
>
> 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?
>
> Wojtek
>
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 2 Mar 2019 17:40:48 +0100
> From: Till Oliver Knoll <till.oliver.knoll at gmail.com>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <db52539e-0b64-a774-3398-2d96fceb3749 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
> Am 02.03.19 um 05:22 schrieb Chris Burrows:
> >> -----Original Message-----
> >> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> >> Till Oliver Knoll
> >> Sent: Friday, 1 March 2019 7:44 AM
> >> To: Oberon Mailing List
> >> Subject: [Oberon] IMPORT Modules: why does order matter?
> >>
> >> Hello,
> >>
> >> It seems that with the Project Oberon 2013 compiler the order of
> >> imported modules seems to matter now ...
> > An example of a situation where it does matter when using the Project
> Oberon compiler:
> >
> > M0 declares a structured type T0
> > M1 exports variable x1: M0.T0
> > M2 declares variable x2: M0 and references M1.x1
> >
> > M2 directly imports M0 but also indirectly imports M0 via M1. In that
> case, in M2's import list should be IMPORT M0, M1.
>
> Hmmm, I kind of see at what you're getting (I believe you meant "M2
> directly imports *M1*" and I guess you meant "x2: M0.*T0" (as a module
> itself cannot be a type ;)), however I am not quite sure if it makes
> sense to me yet.
>
> So here is what I think your example was, for M2:
>
> MODULE M2;
>
> IMPORT M0, M1;
>
> VAR
> x2: M0.T0; (* For this we need to import M0, sure *)
>
> BEGIN
> x2 := M1.x1; (* We access M1 which needs to be imported, too *)
>
> ...
>
>
>
> As we are using explicit types and variables from two different modules
> M0 and M1 it is clear to me that we need to import them both. And I
> understand what you're saying, that since there is a dependency from M1
> on M0, we (M2) also "need to import M0 first (before M1)".
>
> But still I don't understand the exact *why*, except that the compiler
> has become more "lazy" (well, "simpler") than, say, in OberonV4 (or
> Oberon90 - not sure anymore which we used last at the ETH).
>
> Because the import order definitively did *not* matter in earlier
> versions of Oberon (that I know).
>
>
> Thanks,
> Oliver
>
>
> ------------------------------
>
> Message: 7
> Date: Sat, 2 Mar 2019 19:41:15 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <09A16835-E56B-4830-9B10-6C20508F9D9D at yahoo.com>
> Content-Type: text/plain; charset=us-ascii
>
> > Or is the programmer forced to study the import diagrams from the
> book to arrange the
> > lists by hand in the correct way?
>
> Just build the list *once*, e.g. for FPGA Oberon:
>
> Kernel, FileDir, Files, Modules,
> Input, Display, Viewers,
> Fonts, Texts, Oberon,
> MenuViewers, TextFrames,
> System, Edit, Tools
> ORS, ORB, ORG, ORP, ORTool
> Graphics, GraphicFrames, Draw,
> GraphTool, MacroTool,
> Curves, Sierpinski, Hilbert, Stars, Rectangles, Checkers
> ...
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 2 Mar 2019 18:50:57 +0000
> From: "Skulski, Wojciech" <skulski at pas.rochester.edu>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID:
> <
> CY1PR07MB2634E75EC8909CADBD54C0DCFF770 at CY1PR07MB2634.namprd07.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Andreas:
>
> 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?
>
> 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?
>
> Wojtek
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Andreas
> Pirklbauer [andreas_pirklbauer at yahoo.com]
> Sent: Saturday, March 2, 2019 1:41 PM
> To: ETH Oberon and related systems
> Subject: [Oberon] IMPORT Modules: why does order matter?
>
> > Or is the programmer forced to study the import diagrams from the
> book to arrange the
> > lists by hand in the correct way?
>
> Just build the list *once*, e.g. for FPGA Oberon:
>
> Kernel, FileDir, Files, Modules,
> Input, Display, Viewers,
> Fonts, Texts, Oberon,
> MenuViewers, TextFrames,
> System, Edit, Tools
> ORS, ORB, ORG, ORP, ORTool
> Graphics, GraphicFrames, Draw,
> GraphTool, MacroTool,
> Curves, Sierpinski, Hilbert, Stars, Rectangles, Checkers
> ...
>
>
>
>
>
> --
> Oberon at 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_mailman_listinfo_oberon&d=DwICAg&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=uUiA_zLpwaGJIlq-_BM9w1wVOuyqPwHi3XzJRa-ybV0&m=CBGseygccK22G5EVW_cVQMxoTScL1oMi5by75dp_wuA&s=0rJum3W4lLtpwfOqasMOhrlzJjyQQVBZmqDsfGbfj8M&e=
>
>
> ------------------------------
>
> Message: 9
> Date: Sat, 2 Mar 2019 20:06:03 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <40CCF3D3-E5A4-48FD-A988-6EFBA6477AB4 at yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> > 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?
>
> No, you don?t. You only need to import those modules M, whose exported
> constants, types,
> variables or procedures you reference in your module (by name), e.g. when
> you call M.P.
>
> ------------------------------
>
> Message: 10
> Date: Sat, 2 Mar 2019 22:18:12 +0100
> From: Till Oliver Knoll <till.oliver.knoll at gmail.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <50C2B27A-101B-46F4-A12C-1C23CE6CC8A7 at gmail.com>
> Content-Type: text/plain; charset=utf-8
>
>
>
> > Am 02.03.2019 um 19:50 schrieb Skulski, Wojciech <
> skulski at pas.rochester.edu>:
> >
> > Andreas:
> >
> > 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?
> >
> > 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?
>
> I can answer this :)
>
> No, you just need to import the modules which your modules directly uses,
> nothing more.
>
> 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.
>
> 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).
>
> 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.)
>
> 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.
>
> 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 ;)).
>
> So the question I still have (out of pure curiosity):
>
> * 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)?
>
> * Is there a real technical (compiler) reason behind this, e.g. does it
> speed up compilation, greatly simplifies parsing or otherwise is just
> advanteous?
>
> * Or is it really to ?force? the developer in the sense of ?Hey! Know your
> modules!?
>
> 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?
>
> 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.
>
> Cheers,
> Oliver
>
> ------------------------------
>
> Message: 11
> Date: Sat, 2 Mar 2019 23:23:30 +0100
> From: Michael Schierl <schierlm at gmx.de>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <e09e5c43-0c59-02bf-9bee-0fa3949cc39e at gmx.de>
> Content-Type: text/plain; charset=utf-8
>
> Hello Till,
>
>
> Am 02.03.2019 um 22:18 schrieb Till Oliver Knoll:
>
> > 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),
>
> I believe the differences in the commercial offering are only the
> supported features of the emulator (like different virtual RAM sizes or
> network support or HostFS support (to access files on the host from
> within the VM)), not in the source of the Oberon system that is running
> inside. But since I do not own a Mac and have therefore neither used
> "Oberon Core" nor "Oberon Workstation", I cannot tell for sure.
>
> > 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.)
>
> There is no Module "Out" in Project Oberon 2013. See
> <www.projectoberon.com> or
> <https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html> for
> all included modules.
>
> I have made a webpage with syntax highlighted annotated HTML files for
> the Project Oberon 2013 source files, at
> <https://schierlm.github.io/OberonXref/ProjectOberon2013/>. There you
> can also see that there is no "Out" module.
>
> > So the question I still have (out of pure curiosity):
> >
> > * 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)?
>
> The error message is "invalid import order", but it does exist in
> Project Oberon 2013:
>
> <https://schierlm.github.io/OberonXref/ProjectOberon2013/ORB.html#L_142>
>
> Numerical case statements are not implemented there either:
>
> <https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#L_579>
>
> > * Is there a real technical (compiler) reason behind this, e.g. does
> > it speed up compilation, greatly simplifies parsing or otherwise is
> > just advanteous?
>
> Not 100% sure, but I assume it just makes the compiler slightly simpler
> as it can (explicitly) import a module and (implicitly) all its
> dependencies while parsing the actual IMPORT statement instead of having
> to check the dependencies against the modules stated later to make sure
> that the dependencies get imported as explicit imports in the right order.
>
> > And you are supposed to know all their dependencies?
>
> In my experience, trial and error is "fast enough", especially since
> when you get the error, the cursor is on the module that is imported too
> late, so you just successively move it further to the beginning of the
> line until it is accepted. But I am only toying with the Oberon system,
> and do not use it for anything critical (and the number of compile
> errors because of a missing colon in := is vastly above the number of
> import order errors), so your mileage may vary.
>
> > 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.
>
>
> I believe that in Experimental Oberon, import order does not matter, and
> it also supports both Numerical case statements and the Out module (as
> well as procedure forward declarations and some other goodies that make
> your life easier at the cost of making the system more complex). But
> Andreas can comment on that one better than me.
>
>
> Regards,
>
>
> Michael
>
>
> ------------------------------
>
> Message: 12
> Date: Sun, 3 Mar 2019 09:37:50 +1030
> From: "Chris Burrows" <chris at cfbsoftware.com>
> To: "'ETH Oberon and related systems'" <oberon at lists.inf.ethz.ch>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <000901d4d14c$c2e53d30$48afb790$@cfbsoftware.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>
> > -----Original Message-----
> > From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> > Till Oliver Knoll
> > Sent: Sunday, 3 March 2019 7:48 AM
> > To: ETH Oberon and related systems
> > Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> >
> > 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 ).
>
> 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:
>
> "Numeric CASE vs IF THEN ELSE performance"
>
> http://www.astrobe.com/forum/viewtopic.php?f=13&t=552
>
>
> > 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 ;)).
> >
> > So the question I still have (out of pure curiosity):
> >
> > * 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)?
> >
> > * Is there a real technical (compiler) reason behind this, e.g. does
> > it speed up compilation, greatly simplifies parsing or otherwise is
> > just advanteous?
> >
> > * Or is it really to force the developer in the sense of Hey! Know
> > your modules!
> >
>
> Yes - I believe there are elements in all of the above that led to this
> implementation restriction.
>
> >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.
>
> The question of forcing the developer to 'know your modules' is more
> subjective. As a devil's advocate I would ask the question:
>
> Ideally, in what order should the modules be listed on an IMPORT list?
>
> 1. Alphabetic? - useful if they are long lists and you want to know if
> you've missed one.
>
> 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).
>
> 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. ;-)
>
> 4. Something else?
>
> 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'.
>
> 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 :(
>
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com/RISC5
>
>
>
>
>
>
> ------------------------------
>
> Message: 13
> Date: Sun, 3 Mar 2019 00:13:30 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <35CE28C4-F16B-428A-89F1-7FE39020499C at yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> > I believe that in Experimental Oberon, import order does not matter.
>
> 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.
>
> 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).
>
>
> [1] Griesemer R. On the Linearization of Graphs and Writing Symbol Files.
> Computersysteme ETH Z?rich, Technical Report No. 156a (1991), see
> https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/68903/eth-3310-01.pdf
>
> ------------------------------
>
> Message: 14
> Date: Sun, 3 Mar 2019 00:29:51 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <62A81155-DF56-441C-9416-CD7E8BCF620C at yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> > I believe that in Experimental Oberon ? also supports both Numerical
> case statements.
>
> This is correct, see [1] and [2] for more information. But *unlike* the
> Astrobe for RISC implementation (see www.astrobe.com), 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).
>
> Should that modified BC instruction (B,cond PC, [Rn]) become part of the
> ?official? RISC architecture one day (as published on
> www.projectoberon.com), Experimental Oberon would switch over and also
> make use of it.
>
> -ap
>
>
> [1]
> http://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Documentation/Enhanced-FPGA-Oberon07-compiler.pdf
> [2] http://github.com/andreaspirklbauer/Oberon-numeric-case-statement
>
> ------------------------------
>
> Message: 15
> Date: Sun, 3 Mar 2019 00:39:13 +0100
> From: Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>
> Subject: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <0125A3F1-A99C-435E-90F4-83D927B5473B at yahoo.com>
> Content-Type: text/plain; charset=utf-8
>
> > 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.
>
> Such a tool would no doubt be beneficial to FPGA Oberon as well. Except
> that.. where
> are those thousands of FPGA Oberon modules? ;-)
>
> > And to answer your next question - no we don't have a version that
> runs on Apple devices :(
>
> Will there be one one day? You?d have one more user..
>
>
>
> ------------------------------
>
> Message: 16
> Date: Sat, 2 Mar 2019 17:42:03 -0600
> From: oberon at x.colbyrussell.com
> To: ETH Oberon and related systems <oberon at lists.inf.ethz.ch>, Andreas
> Pirklbauer <andreas_pirklbauer at yahoo.com>
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <a60b5025-b6f0-a5c6-e881-fe5ac7df545f at colbyrussell.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 3/2/19 5:13 PM, Andreas Pirklbauer wrote:
> > If one wanted to allow imports to be declared in *any* order [...]
> > cost is <50 lines of additional source lines of code
>
> This topic seems to have taken way too long to get to the answer, and it
> looks like we're still not there.
>
> *Why* does import order matter?
>
> In other words, what would these 50 additional lines of code need to
> ensure?
>
> In other other words, what problem arises in the absence of the
> conditional branch in the compiler that results in this error being
> printed?
>
> --
> Colby Russell
>
>
>
> ------------------------------
>
> Message: 17
> Date: Sun, 3 Mar 2019 00:45:50 +0100
> From: Michael Schierl <schierlm at gmx.de>
> To: oberon at lists.inf.ethz.ch
> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
> Message-ID: <ca1f6ac9-a5bb-ee58-5bb3-0980fccd407b at gmx.de>
> Content-Type: text/plain; charset=utf-8
>
> Hello,
>
> Am 03.03.2019 um 00:13 schrieb Andreas Pirklbauer:
> > I believe that in Experimental Oberon, import order does not matter.
> >
> > The import order *does* matter in Experimental Oberon, just like in
> > FPGA Oberon. This was a deliberate design decision.
>
> Removing forward references was also a deliberate design decision.
>
> On the other hand, the Experimental Oberon compiler backports Oberon-2
> features to make porting code from Oberon-2 easier (To be honest, it is
> still on my TODO list to pick a "random" module from Native Oberon and
> try how many changes are really required to make it compile in
> Experimental Oberon). That's why I assumed import order restrictions
> were also "eliminated" there.
>
>
> But perhaps I should not draw such conclusions without trying it :-)
>
>
> Another example: Experimental Oberon also adds some safety features
> (e.g. with respect to module unloading), yet it does not prevent access
> to uninitialized local (pointer) variables. There is a simple to
> implement solution for that (but that comes with a runtime performance
> penalty):
> <
> https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/initialize-local-variables.patch
> >.
>
> Solutions without runtime performance penalty would make the compiler
> more complex as it has to track that variables are initialized before
> they are used (with the ambiguity whether a variable that is passed via
> VAR to another procedure has to be initialized before or not; similar to
> <ref> vs <out> in C#).
>
>
> Regards,
>
>
> Michael
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
> ------------------------------
>
> End of Oberon Digest, Vol 178, Issue 3
> **************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20190303/db6cd151/attachment-0001.html>
More information about the Oberon
mailing list