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]

Re: catch/throw functionality


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.