[Oberon] IMPORT Modules: why does order matter?

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