🚀 go-pugleaf

anw@maths.nott.ac.uk (Dr A. N. Walker) writes:
>In article <1991May10.162820.2662@maths.nott.ac.uk> I wrote

>    [re a delivered procedure in Algol using a scoped variable "x"]

>>	You could always declare "HEAP REAL x" to give "x" global scope,
>>and then your procedure would work anywhere,

>	I shouldn't post on Friday afternoons!  I started to have nagging
>doubts as I drove home, wondering how to do garbage collection efficiently.
>My copy of the Report is on loan elsewhere, but assuming that Lindsey and
>van der Meulen are right [and they usually are], the procedure is indeed
>scoped by the range of "x", not the scope of "x".  Thus, the above is not
>true, and Steve Knight had a point.

You should never let your Revised Report out of sight :-). However,
you (and L&vdM) are right.

The environs of Algol68 map very well to a stack model, where each
environ is built "upon" another (its dynamic link) and "around" a
third (its static link). By 7.2.2.c, to find the environ "necessary
for" a routine text (or mode definition) C you follow the static links
until you reach one that defines a tag used but not defined in C.

I think this rule is forced not just by garbage collection, but by
code generation issues in general: Even though the value ascribed to a
tag has global scope, the implementation must still store that value
in a 'stack slot'. Under the existing rule, the code generated for a
routine can just follow static links to get at non-local values, and a
value of mode PROCEDURE can just be a code address and a static link.

If the rule was to be relaxed, Algol68 would in effect have closures
(environment, not parameter): In general, the value yielded by a
routine text must somehow contain the values of all non-local tags
mentioned in it, without referring to the _current_ stack. In a
implementation with support for parallelism (and thus multiple stacks)
this might not be hard, but I can see why the committe decided not to
demand it (if indeed they thought about it?).

>This is still not unorthogonal (*all*
>procedures are scoped this way, there is nothing special about procedures
>being returned as results), but it is certainly unobvious.

See also 2.1.1.3.b: {The scope of an environ is not to be confused
with the scope of the values accessed inside its locale. ... } Even
so, most of the time a tag is 'associated' only with the scope of the
value it accesses, not of its defining environ.

--
Lars Mathiesen, DIKU, U of Copenhagen, Denmark      [uunet!]mcsun!diku!thorinn
Institute of Datalogy -- we're scientists, not engineers.      thorinn@diku.dk