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

Re: more srfi-12 rationale?

This page is part of the web mail archives of SRFI 12 from before July 7th, 2015. The new archives for SRFI 12 contain all messages, not just those from before July 7th, 2015.

>>>>> 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
generic scheme.

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