Brian Harvey <bh@abbenay.cs.berkeley.edu> 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

-----
Rob Warnock, 31-2-510		<rpw3@sgi.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: aaanalyst@sgi.com and zedwatch@sgi.com aren't for humans ]