[Oberon] IMPORT Modules: why does order matter?

[Till Oliver Knoll]

> Am 02.03.2019 um 19:50 schrieb Skulski, Wojciech <skulski at pas.rochester.edu>:
> 
> Andreas:
> 
>  imagine I write my own module Acquire which is reading some FPGA registers with direct addressing the FPGA, and writes the number to the system log via Out.Int(value). The only import would be Out. Do I need to import all the other stuff which you listed below?
> 
> In previous Oberons, as well as in BlackBox,  the complete import list was not needed. Is it needed now? If so, can this new feature be fixed as it does not seem friendly?

I can answer this :)

No, you just need to import the modules which your modules directly uses, nothing more.

But if you import several modules, say Display and Oberon, then Display needs (apparently newly) to come before Oberon, as the module directly or indirectly imports Display - according to the module hierarchy.

To be clear: I am using „Oberon Core“, as available in the Mac App Store. For all I know that is based on Project Oberon 2013, and running on some RISC emulator (the RISC CPU designed for the FPGA mentioned in Niklaus Wirth‘s revised Oberon book).

At least my version of Oberon is missing now the Out module. That‘s because „Oberon Core“ is a „bare minimum“ distribution (the company offering it also has a commercial offering), or the module Out has really been deemed redundant and hence been removed in „Project Oberon 2013“ (as you can use a Texts writer and append the Text to Oberon.Log - which is what I think module Out was doing in the end.)

I am only mentioning this because if your „FPGA Oberon“ still has module Out then you might have a different compiler, too, and the import order might not even matter there.

For example the „Oberon Core“ / Project Oberon 2013 (?) compiler I use does not even have the „numerical case“ statement implemented (which is defined for the language „Oberon 07“). So it might as well be that the compiler that I am using is not „fully feature complete“, and maybe someone took a „shortcut“ in validating the IMPORTs (because from a compiler point of view it might be easier to parse/validate „if they are in order“ - unfortunately I have not yet read Wirth‘s compiler book, shame on me ;)).

So the question I still have (out of pure curiosity):

* Do others actually confirm that they get the same „wrong import order“ compiler error (really at the line of the IMPORT, as soon as the first „out of order“ module is found)?

* Is there a real technical (compiler) reason behind this, e.g. does it speed up compilation, greatly simplifies parsing or otherwise is just advanteous?

* Or is it really to „force“ the developer in the sense of „Hey! Know your modules!“

Because if the later I don‘t think that such a „validation“ helps to write better code. As it would not „scale“. Think of importing 3rd party modules. Think of if there would be dozens - well, hundreds ;) - of modules to choose from. And you are supposed to know all their dependencies?

Don‘t get me wrong, I am not trying to critisise, I am genuinely interested in the design decision here. In all simplifications done in Oberon07/2013 I do see the beauty - but not so much here yet.

Cheers,
  Oliver