>>>>> On Sun, 17 Oct 1999 08:26:24 -0400, Richard Kelsey <xxxxxx@research.nj.nec.com> said:

> Works fine for me.  The barf exception gets passed to the outer
> exception handler.

Ah yes.  The problem was my initial *current-exn-handler*.  I
*thought* the model implementation should work, but when my example
didn't, I thought that I somehow misunderstood something about the
call/cc and dynamic-wind interaction.

> He may have convinced you, but he hasn't convinced me.  As Per
> Bothner said, exception systems are normally used to separate normal
> from abnormal results.  Why should sending abnormal results need to
> be *very* cheap?  Or even particularly cheap at all?  It's the
> normal results that have to be delivered quickly.

This may be my ML experience showing.  call/cc isn't part of portable
ML, so people use exceptions to implement short-circuit evaluation and
such-like that I guess you'd claim should be implemented directly with
call/cc in Scheme.  But I still think we should facilitate an
inexpensive implementation, even if the reference implementation uses
generic scheme.

> References: <199910160912.FAA15873@kima.nj.nec.com> Date: Sun, 17
> Oct 1999 00:22:18 -0400 From: Dave Mason <xxxxxx@sarg.ryerson.ca>

>> The SRFI-12 exception mechanism *is* cheap, but the *condition*
>> mechanism isn't cheap at all.  It requires (in general) creating an
>> object for every raised exception.

> You don't have to use conditions if you don't want to.  (Perhaps
> this is the reason for allowing non-conditions to be signalled?)

> And if you do use conditions, there is nothing that requires that a
> fresh condition be signalled each time.  You can make one and use it
> over and over again.  The values in it can be changed via a side
> effect, if you want.

I'm not worried about explicit aborts in my program - I can do as you
say.  My concern is built-in low-level aborts.  Like (/ x 0).  If
these dynamically create ``condition'' values, it will be expensive.

>> I don't like the fact that it needs to do a dynamic-wind and a
>> call/cc to set up an exception and the continuation is actually
>> called whether or not an exception is raised (because it appears
>> that dynamic-wind isn't values-aware).

> I don't understand.  `With-exception-handler' does a dynamic-wind
> but not a call/cc.  Given the handler's dynamic extent there is no
> way to avoid the dynamic-wind (unless you go outside R5RS; some
> implementations have shortcuts for dynamic variables).

> The call/cc is needed in `handle-exceptions' to allow the handler to
> return from from `handle-exceptions'.  The call to the continuation
> for the non-exception case isn't required, that is just the way they
> wrote the code.

I think that handle-exceptions is what virtually everyone will use
(because the exception should run in the enclosing exception
environment).  Hence, they'll get both the call/cc and the
dynamic-wind.

> R5RS says that `dynamic-wind' should handle multiple values.

Quite right.  There was a detail of the implementation that I didn't
understand, which led me to believe that it was dynamic-wind that was
complaining when I tried to get rid of the normal-case continuation call.

> I agree with you, although for different reasons.  Restarts should
> be left to another SRFI.

Without restarts, WITH-EXCEPTION-HANDLER doesn't have to be exposed in
the programming interface, and I see implementation approaches that
could make HANDLE-EXCEPTIONS much lower cost.  With restarts, you
essentially need the dynamic-wind, call/cc pair to do
HANDLE-EXCEPTIONS.  If most built-in exceptions call the
*current-exn-handler* with a constant argument (regardless of whether
or not there are ``condition''s), an abort-only mechanism could
certainly be as efficient as I'd like to see.

../Dave