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

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

25 Feb '18

> 3) Procedure variables. In the compiler, this comes for free. Free in the compiler, but with a small runtime overhead due to the extra indirection when calling the procedure (negligible if the code of the procedure is reasonably long)

1 0

Importing string constants in PO
by Andreas Pirklbauer 24 Feb '18

24 Feb '18

> Importing string constants does not work in PO. > Strings from same module are shown. It’s a know issue in PO2013. When a module M exporting a string s is imported by another module N, an object for the imported string M.s is created in the symbol table of N, with the string position (strx) of s within module M (!) is stored in the field obj.val of the generated object. However, when during compilation of the importing module N string M.s is referenced, a string item will by created via ORB.MakeStringItem which copies the string buffer from ORS.str (i.e. the strings of the importing module N = the module currently being compiled), but using the string position of the *imported* module. That’s the bug. And the reason why you are seeing the strings from the importing module. The fix would be to make string constants aware of modules. Both require rewriting the compiler. Method #1 would be to include the actual strings in the symbol files (and not just their string position). However, this would change the format of the symbol file. Method #2 would be to change the code generated for expressions containing imported strings, such that they reference external strings constants via the SB of the imported module.

3 2

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

24 Feb '18

> I wonder about the assumption that the current > implementation of the Oberon System is somehow > the only reference to decide about the necessity > or utility of features in the Oberon language. It is not. Project Oberon simply drove home the point that one *can* build an OS with the language at hand. That some features not currently in the language (e.g. coroutines) might be useful, or even necessary, in other contexts is undisputed.

1 0

Life without local procedures
by Richard Hable 24 Feb '18

24 Feb '18

Picking up a dying thread: Today, I actually missed local methods when programming in Java: I needed to search through a file line-by-line, splitting each line into parts and comparing some of those parts to the values I looked for. In order to keep the implementation readable, I extracted the line handling code into a separate method. Ideally, this would have been a local method with access to the local variables of the calling method. I ended up creating a private method visible to the whole class, with more parameters than should have been necessary, and accessing member variables where it should only have to access local variables of the calling method. Thus, my vote goes to keeping the support for local procedures in the Oberon compilers, including access to intermediate variables...

5 9

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> Personal style: What I don't like with local procedures > is the following: As the local procedure(s) sit between > the variable declaration and the BEGIN, the local > variable declarations are so far away from > the BEGIN. I don't like to scroll… > Jörg Agreed. And of course, if access to intermediate objects is allowed, it gets even worse - as one (potentially) needs to scroll to *all* intermediate levels as well. And that makes for a lot of scrolling (which only EO handles well ;-) But if access to intermediate objects is *consistently* disallowed for *all* intermediate objects (i.e. not just variables, but also constants and types), then at least one is down to “only” two levels that one needs to scroll to (strictly local, strictly global) - although the described annoyance at the local level remains :-(

2 1

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> I'm confused. This appears to contradict the beginning of your 'PS' above. > When you say 'Oberon' here do you mean the PO2013 operating system? I’m sorry, I was being imprecise in the use of my language. But in essence: 1. The *language report* appears to disallow access to intermediate constants, types and variables within nested scope. 2. The current *compiler implementation* only disallows access to intermediate variables. So the two seem to be out of sync..

1 0

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> but for other objects as types, constants and procedures > this is a bad idea since the cost (in runtime) is null. PS: On a more general note: Just because something doesn’t carry an implementation or runtime cost is a rather poor reason for introducing (or in this case, retaining) a feature. There are equally good reasons for the other way, e.g., to make the handling of intermediate objects consistent (less confusing to programmers, fewer rules to learn), to be able to define a more uniform set of shadowing rules, etc. It can be endlessly debated (and.. not really all that interesting)

1 0

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> By the way, I very welcomed the idea of removing access of > intermediate variables in procedures as this simplify prolog > and saves resources, but for other objects as types, constants > and procedures this is a bad idea since the cost (in runtime) is null. And this may have been the reason why *only* access to intermediate *variables* has been disallowed in the current PO2013 implementation. It just doesn’t comply with the language report.

1 0

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

> I can live without intermediate variables, especially > if they simplify and improve compiler code generation. Only intermediate *variables* complicates code generation and slows down runtime performance (both when calling an intermediate, procedure and when subsequently accessing intermediate variables). Intermediate *constants* and *types* come for free, both in the compiler and at runtime, as their values are known at compile time. PS: This may have been one reason why access to intermediate *constants* and *types* is still allowed in the Oberon-07 revision, whereas access to intermediate *variables* has been disallowed (however: intermediate constants and types are *never* accessed from nested scopes in Oberon).

4 3

Life without local procedures
by Andreas Pirklbauer 23 Feb '18

23 Feb '18

>I was convinced by August Karlstrom's message > that intermediate constants and types as well as > variables are now disallowed in the 2016 Revision > of the Oberon Language report (i.e. Oberon-07/16): > http://lists.inf.ethz.ch/pipermail/oberon/2018/011555.html > However, the PO2013 compiler has not yet been > modified to disallow them. Wirth has stated that > the Oberon Report is the definition of the language > not the PO2013 compiler. The latter has a number > of deviations, restrictions, exceptions and extensions. The fact is that the PO2013 *compiler* only disallows access to intermediate variables from nested scopes, but not to intermediate constants or types (which are, however, never accessed from nested scopes in the entire Oberon system anyway, so nobody noticed...) And which is why I provided a possible implementation, which actually complies with the language *report* at: https://github.com/andreaspirklbauer/Oberon-no-access-to-intermediate-objec… So if the Oberon report is the definition, not the compiler, the compiler would need to be updated. PS: I find section 10 of the report a bit ambiguous, but I guess it can be read such that access to objects (constants, types, variables) are restricted to the strictly local or the strictly global level, whereas intermediate *procedures* can also be called from within nested scopes. This is what is implemented in the above repository. An open question is how shadowing should be handled (one area where the current Oberon language *report* is ambiguous, so I decided with the convention used in the past five decades or so; but it can be debated). Andreas

1 0