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 Wed, Oct 29, 2003 at 09:32:20PM -0800, Bradd W. Szonye wrote: > Shiro Kawai wrote: > > There's another point, though. There are two camps in Scheme > > implementations regarding how to give the "fallback" value, both have > > their own ground. If srfi-44 gives a convincing rationale for thunk > > approach, and becomes widely spread, it may be possible that > > eventually the convention of giving fallback value converges to thunk > > approach. > > I've been thinking about this, and I'd rather raise an exception than > provide a failure thunk. SRFI-34 defines exceptions, and SRFI-35 style > conditions could provide information about the failure. It seems to me > that a language with sophisticated support for continuations should take > advantage of that in failure interfaces. It also simplifies call > interfaces, since you don't ever need to distinguish, "Is this procedure > a thunk or a collection datum?" 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))) Additionally, exceptions have widely varying performance characteristics, whereas all Schemes are written to optimize application of functions. Scott
Attachment:
pgpoL5xvh5ZGY.pgp
Description: PGP signature