>>>>> "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
