>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