[Oberon] IMPORT Modules: why does order matter?

[Michael Schierl]

Hello Till,


Am 02.03.2019 um 22:18 schrieb Till Oliver Knoll:

> 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),

I believe the differences in the commercial offering are only the
supported features of the emulator (like different virtual RAM sizes or
network support or HostFS support (to access files on the host from
within the VM)), not in the source of the Oberon system that is running
inside. But since I do not own a Mac and have therefore neither used
"Oberon Core" nor "Oberon Workstation", I cannot tell for sure.

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

There is no Module "Out" in Project Oberon 2013. See
<www.projectoberon.com> or
<https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html> for
all included modules.

I have made a webpage with syntax highlighted annotated HTML files for
the Project Oberon 2013 source files, at
<https://schierlm.github.io/OberonXref/ProjectOberon2013/>. There you
can also see that there is no "Out" module.

> 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)?

The error message is "invalid import order", but it does exist in
Project Oberon 2013:

<https://schierlm.github.io/OberonXref/ProjectOberon2013/ORB.html#L_142>

Numerical case statements are not implemented there either:

<https://schierlm.github.io/OberonXref/ProjectOberon2013/ORP.html#L_579>

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

Not 100% sure, but I assume it just makes the compiler slightly simpler
as it can (explicitly) import a module and (implicitly) all its
dependencies while parsing the actual IMPORT statement instead of having
to check the dependencies against the modules stated later to make sure
that the dependencies get imported as explicit imports in the right order.

> And you are supposed to know all their dependencies?

In my experience, trial and error is "fast enough", especially since
when you get the error, the cursor is on the module that is imported too
late, so you just successively move it further to the beginning of the
line until it is accepted. But I am only toying with the Oberon system,
and do not use it for anything critical (and the number of compile
errors because of a missing colon in := is vastly above the number of
import order errors), so your mileage may vary.

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


I believe that in Experimental Oberon, import order does not matter, and
it also supports both Numerical case statements and the Out module (as
well as procedure forward declarations and some other goodies that make
your life easier at the cost of making the system more complex). But
Andreas can comment on that one better than me.


Regards,


Michael