[Oberon] IMPORT Modules: why does order matter?

Till Oliver Knoll till.oliver.knoll at gmail.com
Sat Mar 2 17:40:48 CET 2019

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:



	x2: M0.T0; (* For this we need to import M0, sure *)

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


More information about the Oberon mailing list