Subject: Re: Environment model of evaluation [was: Re: The Scheme FAQ]
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 1 Aug 2001 12:49:30 GMT
Newsgroups: comp.lang.scheme
Message-ID: <9k8tsq$7uv02$1@fido.engr.sgi.com>
Max Hailperin  <max@max.mcs.gac.edu> wrote:
+---------------
| rpw3@rigden.engr.sgi.com (Rob Warnock) writes:
| > ... 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, 
| > ...
| > 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. ...
| 
| We need to be careful about what "never reference" and "are
| referenced" mean.  The problem of which are dynamically referenced is
| undecidable.  The usual conservative approximation is to take all that
| appear free in the procedure's body. -max
+---------------

Yes, of course. By "referenced" I meant *potentially* referenced (lexically
visible). Sorry, sloppy language. Strictly speaking, I shouldn't have said
"will never" in the fourth line you quoted, I should have said "cannot ever",
and perhaps been more explicit about the consequences of that. Second try:

    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 cannot *possibly* ever reference (since they
    don't appear free in the closure's body or are shadowed by some other
    variable of the same name).

    If the dynamic extent of the resulting closure is then longer than
    that of the procedure which created it (e.g., it's returned as a value
    or stored in external data), some of the data -- possibly *very large*
    hunks -- may appear to the GC to still be accessible when in fact there
    is actually no longer any way for it to be to referenced. This violates
    the "safe-for-space" desideratum.

    But if mutated variables are all auto-boxed and environments are
    immutable, then when you make a new closure you can copy into the
    closure's environment just exactly the bindings from the ancestor
    environment(s) that are lexically visible, and no others. Then when
    the parent creating procedure returns (or tail-calls something else),
    no excess data will be left "live" to the GC in the new closure's
    environment.

Is that better?


-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 ]