[Oberon] IMPORT Modules: why does order matter?

[Till Oliver Knoll]

Am 03.03.19 um 00:07 schrieb Chris Burrows:
> 
> 
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Till Oliver Knoll
>> Sent: Sunday, 3 March 2019 7:48 AM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] IMPORT Modules: why does order matter?
>>
>> 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 ). 
> 
> That is consistent with Wirth's Project Oberon compiler. We have added numeric case in our Oberon-07 implementation (Astrobe for RISC5). To do this efficiently it was necessary to implement a variant of the Branch Conditional instruction in the RISC5 processor. For more information see:
> 
> "Numeric CASE vs IF THEN ELSE performance"
> 
> http://www.astrobe.com/forum/viewtopic.php?f=13&t=552

Thanks. I already knew that others had already implemented the numerical
case statement. For completeness sake I also found those:

 https://github.com/andreaspirklbauer/Oberon-numeric-case-statement

That maybe even the one that you are referring to. And it is apparently
also implemented (one of the 3 proposed solutions) in "Experimental
Oberon", here:

  https://github.com/andreaspirklbauer/Oberon-experimental

>> ....
>> * Do others actually confirm that they get the same  wrong import ...
>> * Is there a real technical (compiler) reason behind this, ...
>> * Or is it really to  force  the developer ...
> Yes - I believe there are elements in all of the above that led to this implementation restriction.
> 
> From the technical point of view we have only just introduced this restriction ourselves in v7.0 of the Atrobe ARM Cortex-Mx compilers to help resolve some obscure problems reported by a user which were related to direct / indirect imports. When aliased imports are involved as well it can get very tricky. 

Okay, that falls in line with a previous reply that it may indeed
greatly simplify the compiler and the validations it has to do, possibly
even helping in detecting otherwise subtle missing dependencies otherse.

I'll take that as an answer :)

> 
> The question of forcing the developer to 'know your modules' is more subjective. As a devil's advocate I would ask the question: 
> 
> Ideally, in what order should the modules be listed on an IMPORT list?

Well, ideally there should not be any restriction at all. I am not aware
of any other language/compiler which imposes such a restriction in the
order of imports, including previous Oberon compilers that I know.

So the decision should ultimatively be with the developer (team). I tend
to import "system libraries" first, then 3rd party libraries, then my
own ("what is closer to my own sources is imported last, to be closer to
my code in that very source file").

But within each those blocks so far I tend to order them "per use", so
if I first use module Texts, then that would be importend before Display
(for example), in case I only use the Display module later in my source.

> 2. Bottom-up? - useful if you want to know in what order you should recompile them if necessary. Also useful to get an idea what you might break if you modify any of the interfaces (you only need to potentially worry about the modules that come after the one you are modifying). 

Well, this is a valid point, too! Having the import "in the order of
dependencies" indeed helps you to quickly determine the correct order in
which you'd have to (re-)compile your (own) modules, too! So there is
indeed a little "usability gain" for the developer when reading the code.


And yes, I have seen in some Java development that they had a style
guide to sort the includes alphabetically (but still kind of sorted by
"JDK imports first"). But you better have an "auto-formatter" for this,
or else :)

(Unfortunatelly the style guide applied to loca sources was slightly
different than the one on the integration server, so you'd still get
rejects from integration, because of a different opinion on what would
go first, e.g. "javax before java" imports or the other way round - or
so I remember...


> Having spent much time over many decades maintaining code bases with the source code of thousands of modules not written by me I would have been really grateful if the development system had encouraged explicit module references and some sort of ordering of imports rather than leaving it up to the programmer. 

Well, in my experience the ordering was never a problem at all. In fact
the import section you'd have "collapsed" anyway and not even look at it
during reviews. Because if the developer forgot about some import then
that's the job of the compiler to tell.

So you'd focus on the actual code, and that is where it gets very
quickly way more ugly than some "funny import order". ;)

> no we don't have a version that runs on Apple devices :(

No worries :) That's just the computer I happen to use these days at
home. But it has various "virtual machines" installed, too (including
Solaris and FreeBSD), so I am not very "religious" in this aspect ;)



This answers my initial question. Thanks a lot to all who contributed.

Cheers, Oliver