[Oberon] IMPORT Modules: why does order matter?

Chris Burrows chris at cfbsoftware.com
Sat Mar 2 05:22:18 CET 2019

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


Chris Burrows
CFB Software

More information about the Oberon mailing list