[Oberon] Intermediate scopes in Oberon-07

[Andreas Pirklbauer]

> 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 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180209/f3e30427/attachment.html>