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 http://www.szonye.com/bradd