[Oberon] IMPORT Modules: why does order matter?

[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


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

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. 

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?

1. Alphabetic? - useful if they are long lists and you want to know if you've missed one.

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

3. Random? - Useful if you are a contract programmer and ongoing maintenance of your code wasn't specified in your contract later. Also useful if you don't have a clue about what you are doing. ;-)

4. Something else?

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. A development manager should always keep in mind that in the life-cycle of software typically 10-20% of the costs are incurred by the original development whereas 80-90% of the costs are incurred maintaining it. When choosing development tools they would be wise to consider how well the tool helps to encourage good programming practices and lessen the need for themselves to 'herd cats'.
 
Having said all that, I can see this restriction might cause some head-scratching if you are trying to port a large application from an older version of Oberon. However, (shameless plug coming) it is less of a problem in Astrobe because it includes a build tool to ensure that all imported modules are recompiled in the correct order. The output log of this makes it very obvious how to order the modules on an import list if the error should arise. And to answer your next question - no we don't have a version that runs on Apple devices :(

Regards,
Chris Burrows
CFB Software
http://www.astrobe.com/RISC5