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.