This page is part of the web mail archives of SRFI 34 from before July 7th, 2015. The new archives for SRFI 34 contain all messages, not just those from before July 7th, 2015.
>Restarts complicate matters for *all* exception handlers, though. Once >they enter the picture, you have to be careful about side-effecting in >any delegating exception handler, whether it's a finally clause or >not. If we need to avoid side effects, then we're talking about a primarily functional language. I don't think that try/throw/catch and their ilk are the best way to solve this problem for functional (or mostly-functional) languages, especially languages with continuations. Because they are familiar to programmers who have these constructs in other languages, I expect that this SRFI will achieve a final form and be implemented at least in a few places. But I find it comforting that the SRFI process allows for SRFI's that obsolete or conflict with other SRFI's, and that this one reaching a final form will not mean that the question is closed. I think that "the right thing" is going to involve *UNDOING* a procedure call that runs into an exception, and the procedure call that led to it, etc, until call frames back to and including the call frame of a procedure with an exception-handler have been popped. And then the exception-handler would get called with the same arguments that the procedure it's an exception-handler for got called with, plus access to an exception-code that should have gotten passed back down the stack as call frames were being popped until reaching the frame of its caller. This differs from the Try/Catch/Throw thing in that it abandons call-frames and procedure-calls that lead to the exception instead of trying to recover; but the semantics are a lot cleaner. Exception-handlers would not be limited in any way, and could have exception-handlers of their own ad infinitum. They could capture continuations or call captured continuations the same as any other procedure. No critical resources or global variables are implied or required, nothing that creates a race condition in multiprocessing is entangled, and the semantics becomes clean and provable again. The reference implementation is the main reason I haven't submitted this alternate form as a SRFI yet; it's not an easy reference implementation to do, and requires mucking about at a level below the normal capabilities of the language to address. The reference implementation may have to be be a compiler in scheme that emits machine code to do it, rather than a nice "language extension" using define-syntax or lambda. Bear