On Mon, Dec 07, 2009 at 02:28:34PM +0000, Nicholas Clark wrote: > On Sun, Dec 06, 2009 at 09:28:43PM -0500, Bob Rogers wrote: > > From: "Patrick R. Michaud" <[email protected]> > > Date: Sun, 6 Dec 2009 00:01:24 -0600 > > > > TT #1091 and DEPRECATED.pod claim that label-based exception > > handlers are eligible to be removed in 2.1. I think label-based > > exception handlers are necessary; but I'm willing to be proven wrong. > > > > If a handler "should be" a Sub, then presumably a closure should also be > > allowed. In that case, you could create a closure that contained the > > loop_handler body, calling continuations instead of using "goto". But > > not only is that a much more heavy-weight solution, it doesn't avoid the > > inferior runloop issue, either. > > > > Furthermore, if there is an inferior runloop problem with using a > > Continuation as a handler, then there is also a problem with invoking a > > Continuation from a handler. And if that is so, then handler code can't > > make a nonlocal exit, which seems unacceptable in any case. > > Is the inferior runloop problem that > > 1: the exception fires > 2: the exception handler is started in an inferior runloop > 3: the exception handler completes by resuming execution > 4: *that* execution resumes still within the inferior runloop > 5: the inferior runloop completes the program to exit > 6: the inferior runloop exits > 7: the original runloop continues from the point of the exception
Approximately. A bit more detail: 1: we establish an exception handler for a sub 2: the sub calls a function that contains an inferior runloop 3: within the inferior runloop, an exception occurs 4: the exception causes the exception handler to be invoked 5: the exception handler completes by resuming execution 6: *that* execution resumes still within the inferior runloop .... the rest as you have it > in which case, what seems to be needed to allow control exceptions to affect > control flow is > > 1: that the exception handler (or at least the last part of it) runs in > *the same runloop* as where it is declared > 2: (by implication) the exception handler is not allowed to return control to > the point where the exception is thrown IIUC, various parts of the design (for Perl 6) require that we be able to return control to the point where the exception is thrown (for instance, Perl 6's warn() requires this), so any solution that relies on #2 here isn't workable for us. Pm _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
