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.
>
> xxxxxx@freenetproject.org 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
simpler.

	Scott