Re: Backtrace and enhanced catch

[Ludovic Courtès]

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.

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.