Finally clauses Tony Garnock-Jones (09 Aug 2002 14:05 UTC)
Re: Finally clauses Dave Mason (09 Aug 2002 14:58 UTC)
Re: Finally clauses Richard Kelsey (09 Aug 2002 23:28 UTC)
Re: Finally clauses Tony Garnock-Jones (12 Aug 2002 11:24 UTC)
Re: Finally clauses Richard Kelsey (13 Aug 2002 00:48 UTC)
Re: Finally clauses Tony Garnock-Jones (13 Aug 2002 17:35 UTC)
Re: Finally clauses Richard Kelsey (15 Aug 2002 01:47 UTC)
Re: Finally clauses Tony Garnock-Jones (15 Aug 2002 11:11 UTC)
Re: Finally clauses bear (15 Aug 2002 15:19 UTC)
Re: Finally clauses sperber@xxxxxx (29 Aug 2002 08:08 UTC)
Re: Finally clauses bear (01 Sep 2002 20:55 UTC)
Re: Finally clauses Richard Kelsey (01 Sep 2002 22:22 UTC)
Re: Finally clauses bear (04 Sep 2002 03:07 UTC)
Re: Finally clauses Richard Kelsey (04 Sep 2002 06:55 UTC)

Re: Finally clauses sperber@xxxxxx 29 Aug 2002 08:08 UTC

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