[Oberon] IMPORT Modules: why does order matter?

[Andreas Pirklbauer]

Chris - see the inline comments below:


   > I admire your optimism but feel it is not justified, depending on what you mean by 'relatively' easily.
   > While you might have implemented the main features that distinguished Oberon-2 from Oberon
   > there are quite a few subtle differences that remain between Oberon and Oberon-07 (and consequently
   > Oberon-2 which was a superset of Oberon). Many of these are summarised in the documents:
   >
   > 1. "Oberon at a Glance" 
   > 2. "Differences between Revised Oberon and Oberon"
   > 3. "Porting the Oberon Compiler from Oberon to Oberon-07”


It took about a week (of part time work). But that was “just” programming of course! Fully testing
and correctly addressing all the little subtleties that you have alluded to could easily take N times
that - with N being anything from 3 to 10, depending on how polished one wants the result to be.
An arduous task! You’ve made similar comments about the ratio of “pure” development vs testing/
releasing an actual product. I don’t dispute that at all, ok? I *know* that this is what it would take
to make the result “publishable". As Prof. Wirth once stated: “Writing publishable code is exacting”.

So if someone really, really feels strongly about migrating hundreds of legacy Oberon programs
*unchanged*, there is now at least a base to work with - BUT: he would need to go the extra mile.

I just happen to think that this would be a bad idea and a rather big step backwards (see my next
statement below). I too would recommend to re-factor the legacy apps to improve their quality.


   > In my experience with Oberon-07 the statements in the latter document:
   > 
   > "... corrections of unsatisfactory properties of the original Oberon" 
   >
   >"All changes were made in the interest of regularity, simplicity, completeness, and well-structuredness" 
   >
   > has proven to be true.


And this is exactly why it was decided to re-introduce some of the (now implemented) Oberon-2
features on top of Oberon-07 (!) rather than going back all the way to the original Oberon-2 (and
therefore the original Oberon-1) spec. And even that was done reluctantly. Reason: The principal
features of Oberon-2 (such as type-bound procedures, dynamic heap allocation procedures for
open arrays) were *not* adopted in Oberon-07 for pretty good reasons (albeit admittedly still
contentious in some cases) --> see the (at times a little religious) discussions in this very forum,
e.g. on “[Oberon] Class Methods Vs. Procedure variables in Records” sometimes back in 2017.

I really just wanted to see whether it *could* be done *at all* in FPGA Oberon, given that it
would be rather difficult to make OP2 run in FPGA Oberon (just consumes too much heap).

Answer: Yes, it can be done, and the cost is less than or about 400 source lines of code (sloc) -
which happens to be exactly in line with the experiences made when implementing Object
Oberon as a single-pass compiler on Ceres in its day. Which is not surprising of course..


   > Consequently, IMO time would be better spent on refactoring the legacy apps to improve their
   > quality rather than working on retrogressing to the original Oberon characteristics of Oberon-2.


I would tend to agree.


   > If (unlikely) there was a need to bring a large number of legacy apps up to date, then it would
   > be worth developing a conversion tool to perform at least the more mundane modifications.
   > This would be similar to what was done in earlier times with the development of various Pascal
   > to Modula-2 and, later, Modula-2 to Oberon convertors. 


Correct. I would only add that such a tool can only ever be an aid, not more. I’ve used the
Modula-2 to Oberon converter on Ceres in its day, and the experience has been rather mixed.
Manual intervention was still necessary in many cases. Often, it was better to just re-write.

The same would of course be true for a hypothetical “Original Oberon-2” (1990) to “Revised
Oberon-2” (2019) converter. For example, how should one reliably “translate” a procedure with
multiple RETURN statements or a loop with multiple EXIT statements, such that the result is
guaranteed to be equivalent? Or what about access to intermediate variables from within a
nested scope? Shall one add parameters to the procedures? So, manual intervention will 
therefore be necessary in most cases. Which is why I am a little sceptical of such tools,
although they can certainly be helpful in some simple cases, e.g. to re-write every Original
Oberon-2 WITH statement to the corresponding Oberon-07 type CASE Statement .. 
and other things of that nature.

-ap