<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">> From: Skulski, Wojciech <a href="mailto:skulski@pas.rochester.edu" class="">skulski@pas.rochester.edu</a> Fri Sep 29 14:34:06 CEST 2017</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">> 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</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><pre class=""><span style="white-space: pre-wrap;" class="">> 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.
</span></pre><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">Wojtek,</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">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).</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">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.</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">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 <a href="https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstruction2.pdf" class="">https://www.inf.ethz.ch/personal/wirth/CompilerConstruction/CompilerConstruction2.pdf</a></span> <span style="white-space: pre-wrap;" class="">("In fact, programming experience has shown that the access of intermediate level variables is</span><span style="white-space: pre-wrap;" class=""> </span><span style="white-space: pre-wrap;" class="">bad practice and better be avoided. Implementers must welcome this insight, as it makes the static link superfluous.”)</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">Andreas</span></pre><pre style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">
</span></pre></body></html>