Re: Throw and catch, implications for error recovery

[Andy Wingo]

Hi Derek,

On Thu 20 Nov 2008 01:03, Derek Peschel <address@hidden> writes:

> Presumably the upward-only implementation of throw and catch is the
> problem (or part of it).  Is that true?  Is there an easy rule for
> determining which stack frames become non-recoverable?

It's an interesting question.

I don't know how much the debugger gives you -- I haven't really gotten
into using it yet. But what I would want would be that if you install a
pre-unwind handler that captures the continuation, in theory you should
be able to munge that continuation, restarting certain frames with
different arguments, or different expressions entirely.

In practice though, given that we use the C stack, there are only some
points at which setjmp() has been called, and thus only those places to
which we know how to unwind. Practically speaking, this occurs only at
calls to `catch' and `call-with-current-continuation'. So you can
restart where a continuation is captured, or from the start of a catch
block.

Guile should probably add a raise-continuable as r6 has done, to give
the user a better-supported (and cheaper) restart mechanism.

Andy
-- 
http://wingolog.org/