February 2018 - Oberon - mailman3.inf.ethz.ch

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 10 Feb '18

10 Feb '18

Just for the record: Below is a possible implementation of the Oberon-07 compiler that disallows access to ALL intermediate objects, i.e. not just intermediate variables, but also intermediate types and constants. Five lines needed to be changed in the Oberon-07 compiler. This will now catch the type T in the following test program provided earlier: MODULE Test; PROCEDURE P; TYPE T = INTEGER; PROCEDURE Q(x: T): T; (* this is now caught -> “pos 78 must be strictly local or global" *) RETURN 0 END Q; END P; END Test. ORP.Compile Test.Mod ~ Everything else stays the same, e.g. local procedures continue to be allowed, all types of intermediate objects continue to be allowed (i.e. constants, types, variables can all be declared as local objects inside any procedure, whether global or local and at any nesting level). It’s just that the *access* for ALL intermediate objects is now restricted to either the strictly local level or the strictly global (module) level. Andreas IMPLEMENTATION: (see the output of the Unix diff command further down) --------------- 1. ORP.Declarations: PROCEDURE Declarations(VAR varsize: LONGINT); VAR obj, first: ORB.Object; x: ORG.Item; tp: ORB.Type; ptbase: PtrBase; expo: BOOLEAN; id: ORS.Ident; BEGIN (*sync*) pbsList := NIL; IF (sym < ORS.const) & (sym # ORS.end) & (sym # ORS.return) THEN ORS.Mark("declaration?"); REPEAT ORS.Get(sym) UNTIL (sym >= ORS.const) OR (sym = ORS.end) OR (sym = ORS.return) END ; IF sym = ORS.const THEN ORS.Get(sym); WHILE sym = ORS.ident DO ORS.CopyId(id); ORS.Get(sym); CheckExport(expo); IF sym = ORS.eql THEN ORS.Get(sym) ELSE ORS.Mark("= ?") END; expression(x); IF (x.type.form = ORB.String) & (x.b = 2) THEN ORG.StrToChar(x) END ; ORB.NewObj(obj, id, ORB.Const); obj.expo := expo; obj.lev := level; IF x.mode = ORB.Const THEN obj.type := x.type; IF x.type.form = ORB.String THEN obj.val := x.a + x.b*10000H ELSE obj.val := x.a END ELSE ORS.Mark("expression not constant"); obj.type := ORB.intType END; Check(ORS.semicolon, "; missing") END END ; ... END Declarations; 2. ORP.CheckLevel (new procedure inserted e.g. after ORP.Check) PROCEDURE CheckLevel(lev: INTEGER); BEGIN IF (lev > 0) & (lev # level) THEN ORS.Mark("must be strictly local or global") END END CheckLevel; 3. ORG.MakeItem: PROCEDURE MakeItem*(VAR x: Item; y: ORB.Object; curlev: LONGINT); BEGIN x.mode := y.class; x.type := y.type; x.a := y.val; x.rdo := y.rdo; IF y.class = ORB.Par THEN x.b := 0 ELSIF y.class = ORB.Typ THEN x.a := y.type.len; x.r := -y.lev ELSIF (y.class = ORB.Const) & (y.type.form = ORB.String) THEN x.a := y.val MOD 10000H; (*strx*) x.b := y.val DIV 10000H (*len*) ELSE x.r := y.lev END ; IF (y.lev > 0) & (y.lev # curlev) THEN ORS.Mark("level error, not accessible") END END MakeItem; COMMENTS: --------- 1. ORP.Declarations: In essence one now sets obj.lev := level also for constants (previously this was done only for types and variables, but not for constants) I.e. the variable obj.lev is no longer “abused” to hold the length of a (string) constant, but to hold the scope level (this makes it possible to check for it in ORP.CheckLevel). Instead both the address and the length of a string constant are now “encoded” (16 bits each) into a single field (obj.val). This in turn frees up the obj.lev field (which can now used to hold the actual scope level of the constant). Note that x.a and x.b are themselves set by ORG.MakeStringItem (see there; but it does not need to be changed) 2. ORG. MakeItem: It simply performs the inverse operation as in ORP.Declarations. It also removes the guard (y.class # ORB.Const) in the last line of MakeItem that used to be there for handle the special case of constants (..was kind of shady anyway). 3. This implementation makes local procedures “self-contained”, i.e. one can move them around freely, make them global etc. DIFFERENCES: ------------- Differences to the Original Oberon 2013 version (as of Feb 10, 2018) at https://www.inf.ethz.ch/personal/wirth are as follows: $ diff ORP.Mod OriginalOberon2013/Sources/ORP.Mod 31,35d30 < PROCEDURE CheckLevel(lev: INTEGER); < BEGIN < IF (lev > 0) & (lev # level) THEN ORS.Mark("must be strictly local or global") END < END CheckLevel; < 45d39 < ELSE CheckLevel(obj.lev) 803,805c797,798 < ORB.NewObj(obj, id, ORB.Const); obj.expo := expo; obj.lev := level; < IF x.mode = ORB.Const THEN obj.type := x.type; < IF x.type.form = ORB.String THEN obj.val := x.a + x.b*10000H ELSE obj.val := x.a END --- > ORB.NewObj(obj, id, ORB.Const); obj.expo := expo; > IF x.mode = ORB.Const THEN obj.val := x.a; obj.lev := x.b; obj.type := x.type $ diff ORG.Mod OriginalOberon2013/Sources/ORG.Mod 253c253 < ELSIF (y.class = ORB.Const) & (y.type.form = ORB.String) THEN x.a := y.val MOD 10000H; (*strx*) x.b := y.val DIV 10000H (*len*) --- > ELSIF (y.class = ORB.Const) & (y.type.form = ORB.String) THEN x.b := y.lev (*len*) 256c256 < IF (y.lev > 0) & (y.lev # curlev) THEN ORS.Mark("level error, not accessible") END --- > IF (y.lev > 0) & (y.lev # curlev) & (y.class # ORB.Const) THEN ORS.Mark("level error, not accessible") END

1 0

Re: [Oberon] Oberon Digest, Vol 165, Issue 5
by Артур Ефимов 10 Feb '18

10 Feb '18

Andreas Pirklbauer wrote: > However, if this is the line of argumentation, it is hard to see why access to intermediate *variables* should be considered bad programming practice, while access to intermediate *constants* or *types* should not. But there actually is a difference between variables on one side and constants and types on another side. The difference is that one can change the value of a variable after it is defined, but once a constant or a type is defined, it can not be changed, it simply does not have a value to change. This does not however mean that a programmer can't change the type declaration itself in some time in the future, but is it really a problem? Changing a variable's value from an unexpected place in the program is a problem.

1 0

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 10 Feb '18

10 Feb '18

> I have been in contact with Prof. Wirth and he confirms > that "procedure Q should be diagnosed in error." Therefore, > access to any kind of object from an intermediate scope is > not allowed in Oberon-07/16. This holds true even for > parameter types as illustrated by the example above. This is as it should be. Thus, the current implementation just doesn’t implement it (as the example compiles without errors)

3 2

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 10 Feb '18

10 Feb '18

> From: Chris Burrows chris(a)cfbsoftware.com Sat Feb 10 01:28:16 CET 2018 > > The PO2013 system consists of a total of approximately 850 procedures. > I could only find 17 that were local procedures. Of those 17 I couldn’t > find a single example where the enclosing procedure had a TYPE or CONST > declaration. That did not surprise me at all. Interesting statistics. This means that it should be “safe" to change the implementation of the language, such that access to intermediate types and constants is no longer allowed. > However, when I looked a bit further, what did come as a surprise > was that I could find only ONE local TYPE declaration and only eight > local CONST declarations (5 of those in Math.Mod) in the entire system > > If these sorts of statistics were common to other current real world > Oberon applications it would be reasonable to ask whether not only > local PROCEDUREs, but also local TYPEs, are really *needed*. This would leave us with a language that only has *global* procedures and within these global procedures all one can have is local *variables*. i.e. no more local types, local constants or local (nested) procedures. A welcome side effect would be a(n even) simpler compiler. However, I don’t know whether these sorts of statistics is indeed common to other current "real world" Oberon applications. I did a quick check for the Oberon System 3 (ETH Oberon), Oberon V4 (Linz Oberon) and ETH A2 (formerly AOS) systems. At least in those systems, local TYPE and CONST declarations seem to be very rarely used indeed. There are, however, local procedures, in use, just like in PO2013, but not too many. These could certainly be converted to global ones. > All of these features were *absolutely essential* in the Pascal > days when all you had was a single PROGRAM file. But since the > introduction of MODULEs in Modula-2 and the simplification of > TYPEs in Oberon they have become less and less significant Exactly right. One could say that since Modula-2 the module has become the primary information hiding mechanism. > ... or would that be a case of making it simpler > than "as simple as possible”? This is another one of those questions that can be debated endlessly. I would only argue for consistency across the board, e.g., 1. *If* local procedures are kept in the language, *then* one might as well keep local types and constants (as is currently the case in PO13) 2. *If* access to intermediate *variables* (i.e. variables declared in an enclosing procedure scope) is not allowed in the language (as is the case since the Oberon-07 revision), *the*n one should probably also not allow access to intermediate types and constants (this is where Oberon-07 is inconsistent at the moment). Again, I had suggested to eliminate local procedures altogether in the past - now that access to intermediate *variables* is no longer possible (since the Oberon-07 language revision). But it was decided to *keep* local procedures in the language. Regards, Andreas > Regards, > Chris

1 0

Intermediate scopes in Oberon-07
by August Karlstrom 09 Feb '18

09 Feb '18

I'm experimenting with Peter De Wachter's Oberon RISC Emulator available at https://github.com/pdewacht/oberon-risc-emu using the provided disk image from 2016-08-02. As far as I understand, in the latest version of the Oberon programming language no access to intermediate scopes is allowed. Still the compiler accepts the following module: MODULE M; PROCEDURE P; CONST c = 0; TYPE T = INTEGER; PROCEDURE Q; VAR x: T; BEGIN x := c END Q; END P; END M. Haven't Niklaus Wirth updated the compiler accordingly or doesn't the disk image reflect the latest implementation of PO2013 or am I missing something else here? Regards, August

2 3

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 09 Feb '18

09 Feb '18

> Also, one of the reasons for disallowing all access to intermediate scopes is that it allows the declaration of a procedure to be moved outside or inside another procedure without invalidating the module. If the types in the parameter list references an intermediate scope the procedure is not really "self contained." This has been the subject of some discussion after Oberon-7 was released. It‘s one of those topics that can be endlessly debated - similar to the debate held in this forum sometimes last year whether a language should define name or structural equivalence ;-) With respect to access to intermediate objects I have always been a proponent of „all-or-nothing“: either the language allows access to *all* kinds of intermediate objects that may exist in a language (in Oberon these are constants, types and variables) or none at all. In Oberon-07 the „official“ reason given for *disallowing* access to intermediate *variables* is that it represents „bad programming style“. Of course, the compiler implementor must welcome this „insight“ (irrespective of whether he believes that access to intermediate variables is good programming practice or not..), as he can now eliminate the static link in a particular implementation. Great! However, if this is the line of argumentation, it is hard to see why access to intermediate *variables* should be considered bad programming practice, while access to intermediate *constants* or *types* should not. In other words: the argument to promote better programming style seems to fall on its nose, if it is not carried through in a systematic way and applied to all intermediate objects. And just because access to intermediate constants and types (as opposed to intermediate variables) comes for free in an implementation is a rather poor reason for keeping it in a language - especially if the argument for ditching access to intermediate variables had been „bad programming practice“. This is why I would plead for disallowing access to *all* intermediate objects, *once* the decision has been made to disallow access to intermediate variables, and to adapt the language specification accordingly. The implementation is trivial. This would effectively turn local procedures into (self contained) global ones - with the only remaining difference that they can be called only from the enclosing procedure. I have once asked why in that case local procedures are not eliminated altogether from the language. The answer was that sometimes it is desirable to nest a procedure to indicate that it is called only from the enclosing procedure. Retaining local procedures also carried the benefit that no change was necessary in the language specification. This is a major point, once a language is in the public domain. I accept that justification - but of course this can be endlessly debated. Personally I found the argument of „promoting better programming style“ only moderately convincing. But I do acknowledge that it makes it easier to read a program: If I encounter a variable, I only need to look in two places: the strictly local scope and the strictly global scope - but not tje scopes of the enclosing procedures. It also eliminates a potential source if error. Finally, I can freely move a local procedure around without having to worry about conflicts (except for the name of the procedure itself of course, which however can be easily resolved by renaming it). But the argument for a simpler implementation is of course appealing to the language implementor (as the static link is eliminated altogether) - even though an implementation consideration shouldn‘t necessarily influence language design. But as this example nicely shows, one shouldn‘t be completely „blind“ about potential implications for the implementation either. Algol 68 is a good example: the language specification was so completely overloaded with seemingly useful features that it took many years to implement them all (and some simply had no efficient implementation). Hence the impetus for Pascal., Andreas

1 0

Intermediate scopes in Oberon-07
by Andreas Pirklbauer 09 Feb '18

09 Feb '18

> As far as I understand, in the latest version of the Oberon > programming language no access to intermediate scopes is allowed. > Haven't Niklaus Wirth updated the compiler accordingly or > doesn't the disk image reflect the latest implementation > of PO2013 or am I missing something else here? Only access to intermediate *variables* has been restricted in theOberon-7 language revision. This eliminated the need for a staticlink in implementations. Access to intermediate *constants* declared in the surrounding scopescontinues to be allowed in Oberon-7 (constants never used the staticlink anyway). See the guard (y.class # ORB.Const) in the last lineof procedure ORG.MakeItem.

2 1

Re (2): Re (2): Documentation for Fox compiler.
by peter＠easthope.ca 05 Feb '18

05 Feb '18

From: Pablo Cayuela <pablo.cayuela(a)gmail.com> Date: Sun, 4 Feb 2018 18:12:18 -0300 > A better source for Fox - Flexible Oberon Cross Compiler: > > https://trac.inf.ethz.ch/trac/lecturers/a2/browser/trunk/source/Fox.Tool?re… Thanks Pablo. Linked in the glossary now. https://en.wikipedia.org/wiki/Oberon_(operating_system)#Glossary ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca https://en.wikibooks.org/wiki/Medical_Suction_Machines https://en.wikibooks.org/wiki/Oberon

1 0

Re: [Oberon] HotKeys ?
by peter＠easthope.ca 03 Feb '18

03 Feb '18

From: eas lab <lab.eas(a)gmail.com> Date: Sun, 14 Jan 2018 23:44:14 +0000 > It seems that N-O, LNO, LEO have only <F1> as a HotKey ? The N-O keyboard is discussed in http://www.ethoberon.ethz.ch/keyboard.html . The F keys are under the heading "Code Points 80H to FFH". > How much work is needed to make eg. <F2> ... <F2> is connected to neutralize already. > Store the Frame which received the most recent TextEdit? An alternative to an easily forgotten or overlooked key assignment is a command, kept in sight at the top of your personal Tool Text. ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca https://en.wikibooks.org/wiki/Medical_Suction_Machines https://en.wikibooks.org/wiki/Oberon

1 0

Re: [Oberon] Documentation for Fox compiler.
by peter＠easthope.ca 02 Feb '18

02 Feb '18

> I meant "available". OK, we're in the same chapter, if not on the same page. > I did not mean "install A2 natively, then search". A native installation isn't necessary. If you have a *nix system at hand, retrieve Guenter's latest archive in a few seconds and install in a few more. Here are a few lines from Configuration.XML to hint at capabilities.  <Section name="Compilers"> <Section name="PACO"> ... <Section name="Fox"> <Setting name="caption" value="Compile"/> <Setting name="options" value="-p=Linux32G -b=AMD --warnings"/> <Setting name="fileExtension" value="MOD"/> ... <Section name="Fox"> <Setting name="caption" value="Compile"/> <Setting name="options" value="--activeCells -b=TRM"/> <Setting name="fileExtension" value="MDF"/> ... > If Fox is of any value then its documentation needs be available > through modern internet channels. Well, the primary objective at ETH is to teach and students will learn to use the compiler in the first programming lecture or by osmosis. For everyone else, the Web. Eg. https://en.wikibooks.org/wiki/Oberon ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca https://en.wikibooks.org/wiki/Medical_Suction_Machines https://en.wikibooks.org/wiki/Oberon

2 1