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

On Thu, Oct 30, 2003 at 06:29:23AM -0800, Bradd W. Szonye wrote:
> > Bradd W. Szonye wrote:
> >> 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.
> scgmille@xxxxxxxxxxxxxxxxxx wrote:
> > Actually theres a third argument, too.  Is it really an error, or a
> > branch?  I would argue is the latter.  Its not so much that the
> > absence thunk is there 'in case something goes wrong'.  Its more like
> > those operators are acting as conditionals, returning one value when
> > the collection can provide it, and evaluating the thunk if it cannot.
> > This is the semantic argument.
> That's why it "raises an exception" rather than "signals an error."
> While it isn't necessarily an error, it is an exceptional condition,
> because the procedure can't supply the requested data.

Nevertheless, I'm not sure its a good fit with whats happening.  
Besides, both models are possible with an absence thunk:

(define (absence-exception) (raise foo))

(operator value absence-exception)

... while the absence thunk itself is conceptually and mechanically 


Attachment: pgpBJZ2StFybY.pgp
Description: PGP signature