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 (at least in „Oberon Core“, as available in the Mac App Store). That was definitively not the case with OberonV4. E.g. when I have: IMPORT Oberon, ..., Display; I get an „invalid import order“ (or similar) compile error, which I have to „fix“ with: IMPORT Display, ..., Oberon; (Or the other way around - just for illustration). I haven‘t yet figured out the „rule“ of the correct ordering, but I suspect it has to do with the Oberon Module hierarchy, or „lower modules first“. So far I just shuffled the imports around, until it compiles. Is that the expected behaviour of the compiler? If so (out of pure curiosity): what could be the reasoning behind that? Does it simplify the compiler by, say, 3 KByte worth of source code? :) Or is there really a (compiler) technical reason which significantly improves „dependency parsing“? Or does the compiler simply want me to know Oberon‘s module hierarchy by heart? (Mind you, I am not talking about the order of compilation of my modules; that I know. I am really referring to the order of a single import statement). Thanks, Oliver
-----Original Message----- From: Oberon [mailto:oberon-bounces@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 (at least in Oberon Core , as available in the Mac App Store). That was definitively not the case with OberonV4.
E.g. when I have:
IMPORT Oberon, ..., Display;
I get an invalid import order (or similar) compile error, which I have to fix with:
IMPORT Display, ..., Oberon;
(Or the other way around - just for illustration).
I haven t yet figured out the rule of the correct ordering, but I suspect it has to do with the Oberon Module hierarchy, or lower modules first . So far I just shuffled the imports around, until it compiles.
You are on the right track. Although in many case the order doesn't matter IMHO it is a good idea to get into the habit of declaring the lowest-level modules first. It is consistent with the general principle in Oberon that you declare something before you reference it. 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. If you want to know in which order to list any Project Oberon modules the hierarchy of the basic system structure is shown in both tabular and graphical form in Section 2.3 of the Project Oberon documentation. When looking at the graph, import the modules from the bottom up. Regards, Chris Chris Burrows CFB Software http://www.astrobe.com
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
Am 02.03.19 um 05:22 schrieb Chris Burrows:
-----Original Message----- From: Oberon [mailto:oberon-bounces@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
participants (3)
-
Chris Burrows -
Richard Hable -
Till Oliver Knoll