[Oberon] Oberon Text (Question about Oakwood guidelines and design choices)

[Skulski, Wojciech]

Robert:

> I like your idea of a universal Texts but worry about complexity. I need
to learn and play more with porting old code to Oberon-7 to have a
better idea of the challenges.  It would be really handy for software
preservation.

The complexity will be substantial due to two unrelated snags. (A) The conflicting versions of Text. (B) The language was changed. The perfectly good software no longer compiles. 

I hope the following is close to true. Please correct if I got something wrong.

1) The original Oberon Text is a wordprocessor format with ASCII text plus decorations: color, font, and vertical offset. The latter was meant for sub/superscripts. So there is not much complexity there. It is a text, though not an ASCII text. This is described in ProjectOberon1992.pdf, page 78. This is 2005 edition in reality, rather than 1992. I do not think it is any different.

2) The V4 Text is the same editor, plus a way to refer to applets. So you can ask the text viewer to display not only a character (with color, size, offset), but also a rectangle, where some application is displaying some content, with possible animation. You can see it as soon as you open Linz V4: there is a live clock in the System.Tool. It is running. So now Text becomes a collection of graphical applications running "here and there" within the character sequence. The Text Viewer now becomes an application framework, in addition to being an editor. This was introduced by Clemens Szyperski in his "Write−ing Applications : Design of an Extensible Text Editor as an Application Framework". You can get a copy from:
https://www.researchgate.net/publication/2698679_Write-ing_Applications_Design_of_an_Extensible_Text_Editor_as_an_Application_Framework

3) I believe that System 3 did about the same as #2 above, but in a more complex way. I have System 3 installed. It contains the book by Andre Fisher. The detailed Text description must be there somewhere, but I have not found it within a few minutes. But I believe that conceptually speaking it is the same, though more complex.

4) I suspect that FPGA Oberon went back to #1, because its motivation was to preserve the original rather than new development. Chapter 5 of 2013 edition of Project Oberon looks like a copy from the original 1992 edition (which in reality is 2005 edition). It means that the 2013 FPGA Oberon Text is text with decorations, and the application framework is gone. Or better to say, it was not introduced yet. (Oberon time is a cyclic graph. Present is pointing to the past.)

5) I suspect that Andreas' Extended Oberon 2020 is the same as #4, which is #1.

6) I suspect that porting #2 to the FPGA Oberon would entail a complete replacement of the 2013 Text and text frames with the ones from Linz V4. This will not be easy not because of the code, but because of the language: "they" changed the language so V4 will no longer compile. (*)

7) Here we can see how destructive were the language modifications. They were introduced to "improve the code quality". They indeed improved the quality quite a bit: We are back to square one. 

I hope this survey helps. 

W.

(*) In former Eastern Block there was a special phrase to describe such situations: "in order to confuse the enemy". Everyone knew who was the enemy. In the West the closest translation is SNAFU.