Bradd wrote:
>> I've been thinking about this, and I'd rather raise an exception than
>> provide a failure thunk.

xxxxxx@freenetproject.org wrote:
> There are two problems with this.  First, exceptions would complicate
> the code quite a lot.  Instead of:
>
> (operator val (lambda () calculation ...))
>
> We now have
> (with-handler
>   (lambda (error) calculation
>   (lambda () (operator val)))

That's really not much more complicated. It adds only two keywords
(WITH-HANDLER and another LAMBDA), and it actually shows what's going on
more explicitly than the thunk version. However:

> Additionally, exceptions have widely varying performance
> characteristics, whereas all Schemes are written to optimize
> application of functions.

This may well be a major issue with the exceptions approach, especially
given the tendency to put collection code in inner loops. I have a
similar concern regarding the use of coroutines to implement cursors and
multi-collection enumerations. They use continuation objects to manage
control just as exception-handling code does.

Ideally, the best way to handle this would be to design the scheme
implementation with this in mind. If collections frequently use
exception handling and co-routines in inner loops, then it's important
to optimize call/cc. (Alas, my favorite Scheme, PLT, is allegedly one of
the "costly continuation" implementations.)
--
Bradd W. Szonye
http://www.szonye.com/bradd