[Oberon] Procedure variables and local procedures
Andreas Pirklbauer
andreas_pirklbauer at yahoo.com
Fri Sep 29 15:22:57 CEST 2017
> From: Skulski, Wojciech skulski at pas.rochester.edu Fri Sep 29 14:34:06 CEST 2017
> What happens when the enclosing procedure GlobalProc declares its local variables, which are then used within its local procedure? > Local variables are allocated on the stack. Does the "counter" exist when the procedure IncCounter is called by a client module?
> Wojtek
> MODULE M;
> TYPE Proc* = PROCEDURE;
> VAR GlobalProc*: Proc; (*exported*)
> LocalProc: Proc; (*not exported*)
>
> PROCEDURE GlobalProc2;
> VAR LocalVar2: Proc;
> counter: INTEGER; (*allocated on the stack*)
> PROCEDURE ZeroCounter; BEGIN counter := 0 END ZeroCounter;
> PROCEDURE IncCounter; BEGIN counter := counter + 1 END IncCounter;
> BEGIN (*GlobalProc2*)
> GlobalProc := IncCounter; (*allowed (LocalProc2 visible in current scope)*)
> LocalProc := ZeroCounter; (*allowed (LocalProc2 visible in current scope)*)
> END GlobalProc2;
>
> BEGIN (*M*)
> GlobalProc2(); (*assign the variables*)
> ZeroCounter (); (*calling proc local to the module via proc variable*)
> (*IncCounter can now be called by clients. Can it be really?*)
> END M.
Wojtek,
your (modified) module M will not compile when compiled with an Oberon-07 compiler, but return a “level error, not accessible” error message. The reason is that access to intermediate variables is no longer allowed in Oberon-07 (it was in the original version of the Oberon language published in 1988, but it no longer is).
This means that a local procedure (as your procedure ZeroCounter) can only modify *strictly* local variables (i.e. declared local to ZeroCounter) or *strictly* global variables (i.e. declared as global variables in module M), but nothing in between. Therefore, modifying the variable “counter” (which is declared local to GlobalProc2, i.e. at an intermediate level) from within the local procedure ZeroCounter is not permitted in Oberon-07. Hence the error message. And this is precisely the one change in the language that was necessary to make my original version of module M work.
It’s that the language itself has changed with Oberon-07 around 2007, and for good reasons. For some additional insight into this decision, see ch. 12.2. on p.73 of https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstruction2.pdf <https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstruction2.pdf> ("In fact, programming experience has shown that the access of intermediate level variables is bad practice and better be avoided. Implementers must welcome this insight, as it makes the static link superfluous.”)
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20170929/0222c235/attachment.html>
More information about the Oberon
mailing list