Re: Backtrace and enhanced catch

[Neil Jerram <neil@ossau.uklinux.net>]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Better late than never...  ;-)

Absolutely!

> Neil Jerram <neil@ossau.uklinux.net> writes:
>
>> Another (lesser) problem with lazy-catch and with-exception-handler is
>> that they are always used in practice in a particular pattern. [...]
>
> OTOH, this would suggest that `lazy-catch' and `call/cc' are all we need
> to implement `catch'.

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.

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.

>  This is probably the reason why SRFI-34 defines
> no construct equivalent to `catch'.

Actually it does; the `guard' syntax is pretty close to catch.

(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.)

>>From a theoretical viewpoint, it seems to me that it would make sense to
> just keep `lazy-catch' as a primitive and have `catch' implemented as a
> macro on top of it.  Now, from Guile's implementation viewpoint, I guess
> it would be much more costly/complex as you said.

Yes; as well as my points above, we'd like to have something that is
easy to use in the C API.

> Anyway, thanks for your patch: it's nice to see this issue is going to
> be fixed! ;-)  And sorry for not replying earlier.

Thanks for your comments.

       Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel