[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more srfi-12 rationale?
>>>>> On Sun, 17 Oct 1999 08:26:24 -0400, Richard Kelsey <kelsey@xxxxxxxxxxxxxxxxxxx> 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
> References: <199910160912.FAA15873@xxxxxxxxxxxxxxx> Date: Sun, 17
> Oct 1999 00:22:18 -0400 From: Dave Mason <dmason@xxxxxxxxxxxxxxx>
>> 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
> 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.