[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backtrace and enhanced catch

From: Ludovic Courtès
Subject: Re: Backtrace and enhanced catch
Date: Thu, 19 Jan 2006 10:38:02 +0100
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Neil Jerram <address@hidden> 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.


> 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:
> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]