Newsgroups: comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!bloom-beacon.mit.edu!gatech!swrinde!pipex!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Captured lexical environments
Message-ID: <398PVc1w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
Date: Sun, 13 Nov 1994 11:25:25 GMT
Lines: 69

Howdy,
        I know of at least two representations for 
captured, or lambda-bound, lexical environments.
        The first is the "ribcage" model, where
esentially a vector represents the bindings and 
(svref env 0) represents the enclosing lexical
environment.
        The second model takes advantage of the
fact that lambda bound variables that are never
updated can be copied, the values stored in those
bindings that is. Thus only updatable lambda bound
bindings need be "heap allocated" and referenced
via a pointer to a single cell (ok, maybe two cells
if mem is two-cell aligned, but whatever). The
closures then each receive a copy of the cell
reference.
        The "ribcage" model shares heap allocated
lexical bindings, and typical view of these things
is:
        [env]-> #(nil foo 1 3)
        [cod]-> #<Compiled-code 0X12341234>

If two lambda expressions bind the same lexical 
environments, the ribs off the ribcage are shared
among them.
        The copied values/cell-reference model
only shares references to updatable bindings, and
otherwise, values are copied to fresh locations for
each lambda binding:

        [cod]
        [foo]
        [ 3 ]
        [ref]-> #<cell 0x12341234>
        [bar]

[ Sorry, I don't do ascii art very well. ]

        My question is: has anyone compared these 
two methods, "all else being equal". The ribcage
model is "too conservative", in that dead references
might be viewed as "live" by the gc as a lambda
captures a whole "ribcage".
        Alternatively, the copying model could add
additional copying overhead if lexically bound
variables were copied multiple times and could
allocate more memory as well. In its favor, the
copying model is less conservative, and variable
reference will be a single indexed reference
usually, with an extra indirection for updatable
cells.  The ribcage model can require "walking"
the chain of environments.
        Additionally, the "ribcage" model _could_
require manipulating an environment register when
crossing a binding contour, which makes for extra
compiler tracking and/or runtime work. The
copying model only requires setting an environment
register at procedure entry.
        The more I think about it, the more the
copying model looks like a win, but has anybody
done an "empirical investigation" or would like
to share implementation experiences regarding
these two runtime representations of lambda
bound lexical environements?

=============================================
Scott McLoughlin
Conscious Computing
=============================================
