[Oberon] [EXT] Re: Porting S3 / V4 Oberon (was: File transfer)

[Skulski, Wojciech]

Chris:

> Wirth is talking about Project Oberon. You are thinking ETH Oberon / Linz
> Oberon aren't you? There are approximately 350 EXIT's in both ETH Oberon and
> Linz Oberon.

Thank you for the numbers. You are pointing at the problem. I noticed that here in the list the mood seems to be "Lets make a nice improvement of the language, like eliminating the EXIT. Everyone will be happy because one paragraph was cut from the Language Report." The consequence is that the existing application code base has just been thrown out the window. But the Language Report is shorter by 1/4 the page! You would think it should be obvious to avoid such disasters. But no, the so called "everyone" seems to be happy.  And then some folks are surprised that there are no users.

It takes effort to even bring these facts to the attention. Thank you for doing it.

>> Concerning multiple RETURN, I just do not buy the argument that its
>> elimination helps with code quality.
>These are more difficult to identify as there are somewhere between 1000 and
>1500 RETURNs in the ETH / Linz code. It would take significant further
>analysis to identify which are candidates for elimination.

This is why I am suggesting that the compiler needs to be back compatible. Flagging a warning would be fine. It would be a gentle way of saying "you should improve your code, should you not?" There is a difference between warning and breaking the existing code. The latter needs not happen.

It is ironic that some of us discuss the past achievements with nostalgia, while the others are breaking past achievements. In my view both S3 and V4 are monumental programming achievements. No less monumental than Ceres and the original system. Why are we thinking of preserving the latter, while discarding the former? I see no sense whatsoever.

>Also, don't forget there are a number of more subtle differences between
>Oberon 1990 (which Oberon-2 was based on)and Oberon-07 which would cause you
>more headaches e.g. the INTEGER / REAL compatibility rules, the availability
>of certain standard procedures etc. No fatal issues, just death by a
>thousand cuts.

This was partly acknowledged with preserving the LONGINT despite the new Oberon Report. So there was some sense of realism even in the sanctuary. This is encouraging. We only need this realism to expand a bit more. Perhaps unofficially? Perhaps the official mood will be "we never back up a single step", while in reality the back compatibility is preserved under the "undocumented features". It would help. Issue warnings, but do not break all the valuable historical code.

> It is clear that you prefer the Oberon-2 language to Oberon-07.

In fact I do not care, as long as the legacy software can still be compiled. There are man-centuries worth of effort in System-3, in V4, and other software. Have you seen Ants In The Fields? This is not my field, but I can see myself exploring and taking the pieces. If they still compile. Otherwise it is a monumental waste of time and effort. Why are doing it to ourselves? 

> anchovies 

I just had my last can. I need to restock my fridge.

>If, for whatever reason, you want to implement ETH Oberon OS / Linz Oberon
>OS on a hardware platform which does not already support it, the most
>time-efficient way I see of porting it is to first of all implement a
>compiler for that platform that is 100% compatible with Oberon-2.

100% may not be realistic. 95% would be good, 99% would be even better.  I mean, if the compiler tolerates the major points of contention (EXIT, multiple RETURN, and whatever can be realistically done), then porting becomes a manageable project. Otherwise it will be "why are they inflicting all this harm"?

Warnings are OK. Even dire warnings. I will be perfectly happy with a warning message "why do not you remove this EXIT, you stupid".

> If RISC5 is the target, Andreas's work would be a good starting point

It is the only existing starting point to my knowledge.

>, rather than attempting to port the existing S3 / V4 Oberon-2 compilers.

Outside my native field I learned board design and a few other things. Learning compiler technology is possible, but it will be a waste for the community. My time will be better spent if I design a couple boards for all of you. I have this in my plans. If I start working on compilers then there will be neither the boards nor the compilers.

Thank you,
W.