[plt-scheme] Closure Representation

Bindings are always accessed by offset into a value/box stack. When a
closure is applied, its content is unpacked into this stack. When a
closure is created, each value/box added to the closure is obtained
from the stack by offset. The offsets are always determined at compile
time (i.e., local-variable names are all gone by run time).

Hope that helps,
Matthew

At Fri, 18 May 2007 20:31:14 -0400, "Marco Morazan" wrote:
> Thank you for your response Matthew. Flat closures need to be "populated"
> with the bindings of the free variables. Are local functions lambda-lifted
> (or joisted) to simplify this process or is the environment traversed at
> runtime to determine the bindings?
> 
> Thanks,
> 
> Marco
> 
> 
> On 5/18/07, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >
> > At Fri, 18 May 2007 13:59:22 -0400, "Marco Morazan" wrote:
> > > Can anyone point me to a document or web page that describes how
> > closures
> > > are represented in PLT Scheme?
> >
> > What level of detail are you looking for?
> >
> > For the basic architecture, there's no document specific to PLT Scheme,
> > but the implementation is one of the typical points in the spectrum
> > described by textbooks. MzScheme's closures are essentially "flat": a
> > code pointer is packaged with the values (or boxes, in the case of
> > mutable variables) associated with its free variables. For module-level
> > bindings, though, there's an extra indirection: one reference in the
> > closure record to an array of module bindings (and the array is shared
> > for all closures in the same module).
> >
> > If you want to know the actual byte layout for some reason, see
> > `Scheme_Closure' and `Scheme_Native_Closure' in
> > "src/mzscheme/src/schpriv.h". Beware that the `vals' array is not
> > actually an array of values; it can contain mutable-variable
> > indirections and a module-level array, as noted above.
> >
> > Matthew
> >
> >