[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Finally clauses

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