On 09/08/2013 7:57 AM, "David Jeske" <[email protected]> wrote: > > On Aug 7, 2013 9:11 PM, "William ML Leslie" <[email protected]> wrote: > > > Don't finally clauses interfere with this? > > > > I could guess at why you ask, but it's probably better if you say it. > > I interpret your suggestion to mean we install condition handlers which run on the stack of the error, before stack unroll. They could decide to capture the stack or not, because it remains above them. > > If we wish to preserve that stack for future handlers, no handler can be allowed to set the stack pointer (unroll) unless it is ending the exception propagation. This means generated code in handlers needs to reference captured stack contents without using the stack pointer, because it runs down in the stack of the error. > >
Yes, that is what I was getting at. I guess you understand that finally is not the problem - the last instruction branches either to the raise case, continuing to run handlers, or it handles the exception, setting the stack pointer. Finally has to expect to run either in the success case, in which case we are in the original function and should return control there, or we run in the case of a handled exception, which is as above, or an unhandled exception which means branching to the next handler. I guess that is a bit unusual, but that state already needed to be tracked. You correctly point out that such an implementation requires bundling a closure or something for finally (or except) allowing it to use variables elsewhere in the stack. That was already necessary for exception handlers, because they need to know the value to set the sp if they handle the exception. I guess, if in doubt, assume that those before were smarter than you. I think it sounds like a fun technique, which even allows you to replace an exception raise with a value, coroutine style. But maybe it is an experiment for the future, and preserving the traceback should be done in some other means.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
