[Oberon] Intermediate scopes in Oberon-07

Diego Sardina dsar at eml.cc
Sat Feb 17 15:25:22 CET 2018


On Mon, Feb 12, 2018, at 11:15 AM, Andreas Pirklbauer wrote:
> I provide it *only* for discussion purposes. I would prefer eliminating
> local procedures altogether (as it would eliminate the very questions of
> whether one should allow declaring or accessing them).

Sorry, I'm late for this thread.

Local procedures are really useful in structuring mid to big size procedures in small pieces that logically belong to the procedure. I don't like to get the global scope dirty with small procedures that aren't going to be used elsewhere.
One could argue that big procedures are evil, but the truth is that they exist and we have to cope with them.

There are cases where local types make sense.

For example I wrote a procedure that had to process a particular input and I needed a temporary specialised linked-list where items were moved based on some criterias to improve searching.
It's tempting to write this type and its procedures in a separated module or in the global scope, but: 1) It's a specialised linked-list that no other client modules or procedures are going to use it or find it useful, 2) input has to be processed as fast as possible, it's better to avoid the overhead of an external module's procedure, local procedures can be easily inlined/optimised (especially if they can't be passed as parameter or assigned to procedure variables), and 3) it causes excessive modules interdependence, in particular for a single procedure.

A module must be self-contained with less dependencies as possible, for this reason another level of locality at procedure-level is an important feature. Especially in an environment where a module is a piece of loadable unit (as in Project Oberon or Blackbox), it is a waste to use a module just as namespace for small parts of the program.

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.

Having said that, Oberon compilers had always generated small footprint binaries, also with static link. The overhead of the (access via) static link was minimal, also in the Pascal-era, and today is a non-existent problem.




More information about the Oberon mailing list