<div>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? </div> <div> </div> <div>Thanks,</div> <div> </div> <div>Marco<br><br> </div> <div><span class="gmail_quote">On 5/18/07, <b class="gmail_sendername">Matthew Flatt</b> <<a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote:</span> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">At Fri, 18 May 2007 13:59:22 -0400, "Marco Morazan" wrote:<br>> Can anyone point me to a document or web page that describes how closures <br>> are represented in PLT Scheme?<br><br>What level of detail are you looking for?<br><br>For the basic architecture, there's no document specific to PLT Scheme,<br>but the implementation is one of the typical points in the spectrum <br>described by textbooks. MzScheme's closures are essentially "flat": a<br>code pointer is packaged with the values (or boxes, in the case of<br>mutable variables) associated with its free variables. For module-level <br>bindings, though, there's an extra indirection: one reference in the<br>closure record to an array of module bindings (and the array is shared<br>for all closures in the same module).<br><br>If you want to know the actual byte layout for some reason, see <br>`Scheme_Closure' and `Scheme_Native_Closure' in<br>"src/mzscheme/src/schpriv.h". Beware that the `vals' array is not<br>actually an array of values; it can contain mutable-variable<br>indirections and a module-level array, as noted above. <br><br>Matthew<br><br></blockquote></div><br>