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 simpler. Scott
Attachment:
pgpBJZ2StFybY.pgp
Description: PGP signature