[Oberon] IMPORT Modules: why does order matter?

Michael Schierl schierlm at gmx.de
Sun Mar 3 00:45:50 CET 2019


Am 03.03.2019 um 00:13 schrieb 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.

Removing forward references was also a deliberate design decision.

On the other hand, the Experimental Oberon compiler backports Oberon-2
features to make porting code from Oberon-2 easier (To be honest, it is
still on my TODO list to pick a "random" module from Native Oberon and
try how many changes are really required to make it compile in
Experimental Oberon). That's why I assumed import order restrictions
were also "eliminated" there.

But perhaps I should not draw such conclusions without trying it :-)

Another example: Experimental Oberon also adds some safety features
(e.g. with respect to module unloading), yet it does not prevent access
to uninitialized local (pointer) variables. There is a simple to
implement solution for that (but that comes with a runtime performance

Solutions without runtime performance penalty would make the compiler
more complex as it has to track that variables are initialized before
they are used (with the ambiguity whether a variable that is passed via
VAR to another procedure has to be initialized before or not; similar to
<ref> vs <out> in C#).



More information about the Oberon mailing list