[Oberon] [Oberon ] Active Oberon language - a question regarding scope rules

Andreas Pirklbauer andreas_pirklbauer at yahoo.com
Wed Nov 20 20:07:40 CET 2019


    > ETH (Active) Oberon Language Report
    >
    > Added by Felix Friedrich about 1 month ago
    >
    > Although it is work in progress, we have decided to publish the current state of the ETH
    > Oberon Language Report together with the tools in the A2/Oberon repository.
    >
    > It can be found here: export:/trunk/LanguageReport/OberonLanguageReport.pdf
    >

The above Active Oberon language reports states on p.12 (“Declaration and Scope Rules”):

    “An item may be directly referenced within its scope only."

QUESTION: Does this mean that Active Oberon implements "shadowing through scope”? I.e. does an intermediate variable (such as the intermediate variable g declared in P below) block access to a global variable with the same name from within a nested scope Q? 

  MODULE M;
    VAR g: INTEGER;    (*global variable g*)

    PROCEDURE P*;
      VAR g: INTEGER;   (*DOES this intermediate variable “shadow” (=block access to) the global variable g?*)

      PROCEDURE Q;
      BEGIN g := 1           (*OR can a nested procedure Q still access the global variable g here??*)
      END Q;

    BEGIN Q
    END P;

  END M.

For example, in Oberon-07 this leads to a “pos 195 inaccessible” compile time error, so Oberon-07 DOES implement shadowing through scope.

Historically, most Algol-like languages have traditionally implemented shadowing through scope. However, in the earlier languages (Algol, Pascal, Modula, Oberon 1988) access to surrounding scopes was actually ALLOWED, so the shadowing concept made perfect sense.

But in Oberon-07 (and Active Oberon I suppose) intermediate variables can no longer be accessed from within nested scopes. So the question is whether shadowing still has its place in such languages or whether it should be abolished.

Allowing access to the global scope - regardless of whether intermediate variables with the same name exist or not - would effectively make nested procedures self-contained in the sense that they can be moved around freely. For example, procedure Q could now be made local to procedure P without having to worry about whether one can still access the global variable g or not (as the scope of P is simply ignored).

-ap









More information about the Oberon mailing list