On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
> I'd like pushing exception handlers to remain simple -- the current > system is almost OK. What I'd like it to change to is: > > push_eh label > > with popping the top exception handler being: > > pop_eh > > I'm up for better names, too.
The "push_" is okay but "eh" is meh. push_handler seems better, though "handler" is terribly generic. If the documentation and comments use it consistently only for exceptions, though, it could work.
Throw....catch, so
push_catcher ?
I guess the HLL compiler needs to ensure that for every push the control flow will always pass through a matching pop. Otherwise that'll be another hard to debug situation.
Hopefully not. This is partially handled by the push/popmark stuff, partially handled by stack unwinding on 'returns', and partially handled by the sub-private nature of stacks.
Within a sub (or method, whatever) generated code can use the pushmark/popmark ops to manage control stack elements. I expect this'll be done mostly for entering and leaving scope -- code like:
foo: {
bar: {
}
}
outsidefoo:would push a mark for foo when that block is entered, then push one for bar when *that* block is entered. When bar's left the exit code does a popmark bar, while exiting the foo block would exit a popmark foo. If code in bar did a goto outsidefoo, the compiler would see that it was exiting both the bar and foo blocks and just do a popmark foo (since that'd pop all bar's entries too)
Each sub in parrot basically has its own private set of stacks, and doesn't directly connect to its invoker's stacks. (Those are only available from the return continuation tucked away in the interpreter structure, so parrot can get to it easily enough) If code invokes a continuation then the current stacks all go away (more or less -- unless there's a continuation holding on to them, but even then they're out of view) and the stacks in the invoked continuation get put into play, so any exception handlers that were in effect no longer are. Or, rather, the ones that were in scope when the continuation was taken are put back in scope as part of switching over to the control stack that's held in the continuation.
Finally, when a 'return' op is invoked (basically one that puts the return continuation back in play either through a real return or a tail call) the op itself walks back the current control chain (which, remember, is just for the current sub so it should be short) and virtually pops all the elements off it, which means any element that does something when popped will get a chance to do its thing.
Now it's distinctly possible there are more things that should go on the control stack besides exception handlers, marks, and "run my code when I'm popped" entries, so we can add those in as we need.
Tim [ignore me if I'm talking nonsense]
Nope, not nonsense. Things are just a bit fuzzy, so some explanation's in order. :)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
