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.
>>>>> "Bear" == Ray Dillinger <bear@xxxxxxxxx> 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