[Oberon] IMPORT Modules: why does order matter?
andreas_pirklbauer at yahoo.com
Sun Mar 3 00:13:30 CET 2019
> 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  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).
 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
More information about the Oberon