<div>Hi Matthew,</div> <div> </div> <div>Thank you for the answer. I suspected as much as far as indexing the stack. My question is related to the creation of closures. When the values are obtained from the stack is only the "top" of the stack accessed ( i.e. all values are local to the funtion being evaluated that will return the closure) or do free variables still exist at runtime (i.e. the indexing can be to bindings that are not local to the function being evaluated)? </div> <div> </div> <div>To illustrate this:</div> <div> </div> <div>(define (f x)</div> <div>   (define (g y)</div> <div>       (.....y......x....)))</div> <div> </div> <div>Clearly, y is local and only requires indexing the top of the stack. The reference to x is what I am inquiring about. Are the values pushed onto the stack for f accessed while g is executed or is g lifted to the global level (and x added as a parameter) to make all accessess to the top of the stack at runtime? </div> <div> </div> <div>Cheers,</div> <div> </div> <div>Marco<br><br> </div> <div><span class="gmail_quote">On 5/20/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">Bindings are always accessed by offset into a value/box stack. When a<br>closure is applied, its content is unpacked into this stack. When a <br>closure is created, each value/box added to the closure is obtained<br>from the stack by offset. The offsets are always determined at compile<br>time (i.e., local-variable names are all gone by run time).<br><br>Hope that helps, <br>Matthew<br><br>At Fri, 18 May 2007 20:31:14 -0400, "Marco Morazan" wrote:<br>> Thank you for your response Matthew. Flat closures need to be "populated"<br>> with the bindings of the free variables. Are local functions lambda-lifted <br>> (or joisted) to simplify this process or is the environment traversed at<br>> runtime to determine the bindings?<br>><br>> Thanks,<br>><br>> Marco<br>><br>><br>> On 5/18/07, Matthew Flatt < <a href="mailto:mflatt@cs.utah.edu">mflatt@cs.utah.edu</a>> wrote:<br>> ><br>> > 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 <br>> > 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>> ><br></blockquote></div> <br>