Brian Harvey <firstname.lastname@example.org> wrote:
| 2. As an implementor's issue, if the environment is immutable, that
| gives the implementor more flexibility in the handling of environments.
| In particular, when you make a new frame, you can just *copy* all the
| bindings from its parent environment, making a completely self-contained
| new environment, if you want.
There was a long thread here a while back that pointed out that this
is actually *not* just an implementor's convenience issue or a pedagogical
issue, but in some cases can be considered a correctness issue as well --
specifically, whether certain kinds of Scheme code will be "safe-for-space"
in a given implementation. The problem with the typical pedagogical simple
"linked chain of ancestor environments" model is that when making a closure
you close over *all* the lexical variables in the ancestor environment(s),
even ones the closure will never reference, because (with that model) you
*have* to fo so in order to preserve proper sharing of mutated variables.
But if mutated variables are all auto-boxed and environments are immutable,
then when you make a new closure you can copy just exactly the bindings
from the ancestor environment(s) that are referenced by the closure, and
no others. This has two advantages: (1) The new lexical environment is
"flat" -- when referencing a variable there's no need to search a linked
list to find the proper ancestor frame, nor is a "display" needed to
avoid the list chaining; and (2) Data in an ancestor environment that
isn't referenced by the new closure can be garbage-collected [which is
what the safe-for-space issue was all about -- you can't GC such data
with the list-of-ancestor-frames model].
Rob Warnock, 31-2-510 <email@example.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: firstname.lastname@example.org and email@example.com aren't for humans ]