[Oberon] IMPORT Modules: why does order matter?

[Till Oliver Knoll]

Am 02.03.19 um 23:23 schrieb 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. ...
> 
> 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)),..

Yes, that is my understanding so far, too. And the actual Oberon modules
shipped with "Oberon Core" are the ones as described in the 2013 revised
edition of the book "Project Oberon", which I am now eagerly reading :)
Available here:

https://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

(and that site also lists all available modules - without module Out).

> I have made a webpage with syntax highlighted annotated HTML 

As an aside: don't tell anyone else, but I am mostly using Visual Studio
Code to refactor my own "student's exercise source code" ("GigaDraw").
And there is an "Oberon Language Support" plugin with syntax
highlighting and - beware - even code completion. Which I guess is based
on some "built in heuristics and assumptions" - e.g every then and when
I am still seeing procedures from Oberon 1990 when accessing some module
like "Display" (e.g. the "clipped" variants are still suggested, I
believe). But that's okay and is fully made up by supporting the arrow
keys on the keyboard ;)

(Well, probably everybody here already knew about this "Oberon Language
Support" plugin - but it's nice to see that Oberon - somehow - is kept
alive over all those years still :))


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

Yes, that's exactly the message (sorry, I was writing from my mobile
phone yesterday).


>> * Is there a real technical (compiler) reason behind this...
> 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 ...

Then that is probably the reason. At least such a reason would be "in
line" with other simplifications done in PO2013, so I'll take this as an
answer then :)

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

Well, sure, it is not the end of the world, and once you know it you can
start adding modules (and luckily Oberon is small enough to know about
them still ;)) in the right order from the very beginning.


> 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 in the same position, well, maybe more in the "archaeological
department", trying to unearth my student's exercises ;)

But I can tell you from my professional experience (which includes
C/C++) that a simple = in an IF condition goes undetected far more in
practise than you will do the = vs := mistake.

Well, nowadays most C++ compilers spit out at least a warning when they
see you doing if (a = b) {...}, but you are still free to ignore it. If
you're lucky you'll notice right away in your test run. If not... well,
such errors can live for a looong time ;)

Anyway, I am sure the above discussion has been held here a lot already,
and we all know that Oberon has a far superior syntax than most other
languages ;)


But still: the times that I keep adding a "superfluous" ; at the end of
the "last statement" (and where the compiler is furiously bitching at me
with a short "no end" compiler error) also far exceed the number that
I'd wish for ;)


> 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 

Well, personally I've seen people doing forward declarations, but it was
almost never the case where you could not simply move the
implemementation up to the "correct place" and then do without a forward
declaration.

In fact, people claiming that forward declarations are a good thing are
mostly those that freely mix "private" and "public" methods, without any
kind of (visible) sorting. They just keep adding their implementations
where they see fit (mostly right in front of the other
procedure/method/whatever which uses it initially, and once they realise
that another procedure "up there" also requires to call it, they simply
add a forward declaration out of pure lazyness). That is my experience
anyway. Maybe there *are* good use cases for forward declarations. So I
am just saying that I have never seen such cases yet.

But yes, smooth scrolling :) I will definitively check out "Experimental
Oberon" just for this alone. And the numerical case statement certainly
is also useful (especially since it has been "approved" by Niklaus Wirth
even, in his Oberon-07 report).


Thanks a lot!
  Oliver