(Previous discussion continued)
Re: more srfi-12 rationale? Richard Kelsey 17 Oct 1999 12:26 UTC

Re: more srfi-12 rationale? Richard Kelsey 17 Oct 1999 12:26 UTC

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

   Dave Mason wrote:
   >But there's still a problem with the implementation.  Try:
   >   (handle-exceptions
   >      foo
   >      (abort 'barf)
   >      (abort 'blat))
   >but have your hand near your ^C key.

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

 (handle-exceptions bar
                    `(got ,bar)
   (handle-exceptions foo
		      (abort 'barf)
     (abort 'blat)))

 -> (got barf)

   >It's pretty clear to me that the exception handler should have the
   >exception context of the HANDLE-EXCEPTIONS, rather than itself!

The SRFI-12 folk agree with you: the specification requires this
and the implementation does it.

   >In reading the RnRS archive, I became quite convinced (primarily based
   >on the compelling arguments of one of the authors of SRFI-12) that
   >setting up an exception handler and taking an exception should be
   >*very* cheap.

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.

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

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

   >This seems a lot heavier-weight than I would
   >like.  It appears that this is because exception handlers can return
   >as well as abort (exceptions in ML are only of the latter type).
   >Personally, I'd be perfectly happy with exceptions that only could

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