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

Re: API conflicts

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

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

scgmille@xxxxxxxxxxxxxxxxxx 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