>>>>> "Bear" == Ray Dillinger <xxxxxx@sonic.net> writes:

Bear> I think that "the right thing" is going to involve *UNDOING* a
Bear> procedure call that runs into an exception, and the procedure
Bear> call that led to it, etc, until call frames back to and including
Bear> the call frame of a procedure with an exception-handler have been
Bear> popped.

I don't understand what you mean by "undoing":  If the program
communicates with the external world, there's no way in general to
undo what you've done.  I also don't understand why you want to do this.

Bear> This differs from the Try/Catch/Throw thing in that it abandons
Bear> call-frames and procedure-calls that lead to the exception
Bear> instead of trying to recover; but the semantics are a lot
Bear> cleaner.

Again, I don't think I understand: TRY *does* unwind the continuation
back to the exception handler.

Bear> They could capture continuations or call captured continuations
Bear> the same as any other procedure.  No critical resources or
Bear> global variables are implied or required, nothing that creates
Bear> a race condition in multiprocessing is entangled, and the
Bear> semantics becomes clean and provable again.

What precisely are the semantic issues with SRFI 34 you're worried
about?  I sure don't see any that would create race conditions or
interact unpleasantly with multiprocessing.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla