On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote: > I have some clarification questions about the new pdd20 on lexical > variables -- likely stemming from my having been out of it for so > long. Also I am happy to send a patch to pdd20 capturing these > clarifications once I am sure I understand things correctly.
Hey, so this is doubly useful. :-) > 1. What is expected to be in P0 in: > .lex "$a", P0 The ".lex" directive is compile-time only, and has no runtime effect on the contents of P0. (Of course, once a register is available with a lexical name, "store_lex" may modify it.) > 2. Should we provide a way for a compiler to provide depths to the > find_lex and store_lex ops if it chooses to? Maximum depths, you mean? I know of no use case for it. > 3. 'Call frame' is mentioned often--what is a call frame in the > context of continuation passing style? I think "activation record" is the usual term of art. If that's right, and now that I just remembered it (!), I'd welcome a patch that fixes the terminology. > 4. In the section "Closure creation: Capturing the lexical > environment", LexPad is used a couple of times when LexEnv is meant, > right? Fixed. Also, while I was at it, I think I fixed nested closures. At least, I fixed the spec for them. :-) > 5. Thinking about closure support vs. outer support - the difference > and the need for both mechanisms is not clear to me. Could you unpack this, please? > 6. The pdd mentions walking the call stack to find frames ... but is > there a call stack? I call it that mostly for historical reasons. From any given starting point, the records form a singly-linked acyclic list. The overall set of activation records is a tree, with child nodes pointing to parents. > And finding lexpads on the call stack makes me think of dynamic > variable binding rather than lexical? Well, only call frames that belong to textually enclosing subroutines are considered. The old lexical system ignored textual enclosure, which made it broken in all the ways you might think. > 7. Finally, what is the status of the implementation? AFAIK, it all works from the user point of view, except that there are no LexEnv objects per se. Leo has written the pdd20 closure support in a way that keeps more live data than the LexEnv approach. Closures thus use more memory than necessary, but as a result, they may be a lot faster to create. I need to evaluate this to decide whether it (1) works in a way I can live with and (2) even if it does, if the memory issues mean that it needs to be replaced with a real LexEnv. > (As an aside is there interest in having the names of the invoke ops > more consistent, say: callcc and callcc_method; or invokecc and > invokecc_method?) I'm not planning to rename any opcodes ATM. As Allison correctly observes, PIR is an assembly language, not an HLL. So the barrier to cosmetic cleanups is higher. -- Chip Salzenberg <[EMAIL PROTECTED]>
