[Oberon] IMPORT Modules: why does order matter?

[Jörg]

Andreas

Automatic replacement of EXIT is something along these rules:
* LOOP statSeq END                            —> done := FALSE; REPEAT statSeq UNTIL done;
* IF cond THEN statSeq; EXIT END;   —> IF cond THEN statSeq; done := TRUE
  statSeq2                                                      ELSE statSeq2
                                                                       END

br
Jörg

> Am 03.03.2019 um 11:19 schrieb Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>:
> 
> 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
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon