Neil Jerram <[EMAIL PROTECTED]> writes: > Theoretically, perhaps. But if you accept the gist of my analysis, > that would be to build something that has nice clear semantics (catch) > on top of something that has rather awkward semantics (lazy-catch), > which doesn't seem sensible.
Yes, but internally, there is necessarily some form of `lazy-catch', i.e., there is code that executes just after the exception was raised and just before the stack is unwound. So it seems that `catch' is just hiding this away. OTOH, you comments about the environment in which the `lazy-catch' handler gets run, the fact that it must not return, etc., make it clear why it deserves the qualification of "awkward semantics". ;-) > And for Guile (as a particular Scheme implementation) there is a > further reason against this, namely the runtime cost of call/cc. > catch in Guile is much more efficient than code using call/cc to do > the same thing. Agreed. > Actually it does; the `guard' syntax is pretty close to catch. Right, I had misunderstood `guard'. > (BTW, in connection with `guard', which was called `try' in the > original draft of SRFI 34, I came across this email in the discussion > archive: http://srfi.schemers.org/srfi-34/mail-archive/msg00013.html. > This email concludes: > > Robust and portable code should only use the "try" form. > > for reasons connected to how dynamic state is handled that I think are > similar to the reasoning in my analysis. > > If accepted, this conclusion leaves SRFI-34 incomplete, because > try/guard provides no way of running something in the context of the > original error.) Well, you still have `with-exception-handler', except that it must be used carefully. In the light of your comments, it looks like your patch is the way to go! Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
