From: Allison Randal <[EMAIL PROTECTED]> Date: Thu, 16 Nov 2006 17:29:57 -0800
Bob Rogers wrote: > The attached patch adds a docs/pdds/pddXX_dynbind.pod file, which is > a proposal for dynamic binding in Parrot. Please give this a read, when > you have a chance, and let me know what you think. (For those who would > rather not patch their Parrot in order to read it, I also have it up on > my site at http://rgrjr.dyndns.org/perl/pddXX_dynbind.html .) Thanks very much for putting this proposal together. You've worked through a number of important issues. In general, you've got the right idea. A few observations: - It's not stack unwinding/rewinding, so let's not call it stack unwinding/rewinding. Need a new phrase. When I first brought the topic up, I called it "rezipping" -- and I still like the word, as it's visually very appropriate. It even lends itself to "zip up" and "zip down" for describing the parts of the detailed algorithm. But then I rewrote it all to use "unwinding" and "rewinding" because I thought it would be a bad idea to introduce new jargon where it wasn't really needed. So I'm certainly amenable to alternatives. - "Store once" Locations isn't really a good fit for the dynamic nature of Parrot. You're absolutely right; this is too stringent. I was trying to prevent Locations from being stored into while in use as a dynamic binding, as that could have effects outside the normal dynamic scope. That might cause hard-to-debug problems in user code, but avoiding such problems is not worth the price. I will change this paragraph to read: Locations slots should never be changed while the Location is in use by Parrot as a dynamic binding. Doing so can have unintended side effects outside the normal scope of the binding, especially if there are other bindings of the same location in effect. But with continuations, you never know when a binding that is out of scope might come back in again . . . - Overall, I want the implementation of dynamic binding to be tied in more closely with the implementation of globals and lexicals. Particularly lexicals. They're already operating under the same scope constraints as locals. They already have storage for named variables relevant to a particular scope, and the mechanism for handling scopes within scopes. I'm afraid I don't follow you, particularly the "operating under the same scope constraints" part. It seems to me that lexical variables are orthogonal to dynamic/global variables, and dynamic binding is purely a feature of globals. And lexicals are necessarily simpler, because all possible references are available to the compiler. So nested scopes are handled by the compiler simply by using a different register. Globals and dynamic bindings, because they must be visible to code in multiple compilation units, must necessarily use different mechanisms. - I like the idea of "thread locals": global variables shared across threads, but with a local value in one particular thread. I'll have to mull that one over some more. It seems fundamentally different from "scope locals", to the point of deserving a different way of interacting with the feature (perhaps more closely tied to the concurrency model than to variable storage). By "local value" I assume you mean "local binding," which (in the version I posted) would indeed be per-thread. But in what sense are "global variables shared across threads"? Without the binding, all you have is the name, which isn't terribly variable. And "scope locals" -- aren't all variables local to their scope by definition, even if that scope happens to be universal? So I'm pretty sure I must be misunderstanding something . . . - We keep adding hacks to get around the fact that Parrot doesn't handle scopes smaller than a compilation unit particularly well. If we tackled that quirk, dynamic binding would likely fall out more naturally, not to mention exception handlers, lexical variables, etc. Allison I'm afraid I don't follow this, either. "Scope" is mostly an HLL concept; what would Parrot need to do to support them better? Or are you talking about debugger annotation for variable lifetime? -- Bob
