Dan Sugalski <[EMAIL PROTECTED]> wrote:
... A scope exit action is put in place on the control stack with:
pushaction Psub
* What is the intended usage of the action handler? * Specifically is this also ment for lazy DOD runs? * How is the relationship to the C<pop_pad> opcode?
The action handler is there to provide the languages as a way to do something when scopes are left. It's a generic 'out' for stuff that we've not thought about. Most scope exit stuff is cleanup which we'd rather be done via the DOD/GC system (otherwise things go Horribly Wrong in the face of continuations) but there may well be things that need doing.
The one thing that I figure *will* be done is that languages will push a sweep or collect op in their scope cleanup in those cases where the language knows that there's potentially easy temp cleanup that needs doing, for example filehandles that should be closed when the scope's exited if there are no outstanding references to them. (And I know we've got the aggressive GC system for things like that, but in most cases languages can use something a bit less aggressive -- do a full sweep to clean up anything that's actually dead, and anything that escapes scope can be picked up later, since it's lifetime's probably gone nondeterministic)
As far as pop_pad goes, I think maybe we need to revisit the control stack ops to see if some of them can go. (There are a fair number of rough draft things in the pad handling design that need editing) Possibly push_pad too, which could be handled with pushaction, or come up with a lighter-weight scheme to do something similar. Or it may be that there are few enough things that it's worth keeping push/pop_pad around. Not quite sure right now, but we should nail that one down.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
