This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Jim Blandy <jimb@red-bean.com> writes:
> However, those objections don't necessarily mean that catch and throw
> need to be changed; they may simply need to have their use codified.
Yes, I particularily don't like the convention that errors are
detected by counting the number of the throw-args. But I have no
improvement to propose...
> > Key may also be the value `#f'. In that case, THUNK takes one
> > argument which will be passed a "jump buffer object". A jump
> > buffer object may be used as the key argument to `throw' to throw
> > to a specific `catch' without an intervening search for a symbolic
> > key.
>
> I don't know the original motivation for this feature, but it looks
> like a mindless optimization. I have no attachment to it.
Hmm, I think this is quite clever, actually. I think it is supposed
for efficient implementation of a "return"-like feature. Like
(defmacro body forms
`(let ((body-proc (lambda (return) ,@forms)))
(catch #f
(lambda (return-point)
(body-proc (lambda (val) (throw return-point val))))
(lambda (key val)
val))))
(pk 'return (body
(pk 1)
(return 2)
(pk 3)))
But then again, it is probably unlikely that there are a large number
of catch/throw activations between the return-point-establishing-catch
and the invocation of return. So bypassing the search for a symbolic
key might not be a significant improvement. But it is at least
elegant, IMO.