Re: SRFI 34

[Marius Vollmer <mvo@zagadka.de>]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Our lazy-catch implementation specifically unwinds dynamic context so
> that we see (handler #f) here rather than (handler 12).  Effectively
> the only thing that lazy-catch doesn't unwind is the stack. 

Ahh, I see.  The lazy-catch was introduced so that one can get at the
call stack via 'make-stack', right?  If so and it is consistent with
the docs then we should leave it the way it is.  Maybe the docs need
some carification.

> Unwinding the fluid context is contrary to my intuition, though, and
> it appears to yours also.

Yes, but I don't think we should change such a fundamental thing about
lazy-catch just so.  We can introduce a new function, however.
Probably we should just move SRFI-34 into the core and rewrite 'error'
to use it.

But given the semantics of lazy-catch, I think your implementation of
SRFI-34 is wrong.  I does _not_ run the handler in the dynamic context
of the call to 'raise' since lazy-catch winds back to the dynamic
context of 'with-exception-handler'.

Can we use the sample implementation, and just change it to use a
fluid for the list of exception handlers.  Also, maybe we can replace
some call/cc with 'catch', but that would just be for performance.

> One option then would be to have separate wind lists
> for separate kinds of dynamic context, and only unwind the list with
> the catches in it.  But I wonder if there are strong theoretical
> reasons why having separate wind lists would be a bad thing?

That would be quite unclean, I think.  If we want to change lazy-catch
to not unwind the dynamic context (which I think we should not), then
we only need to modify scm_ithrow a bit to not call scm_dowinds for a
lazy catch and to not reset the dynwinds list.  It would just look
into the dynwind list for the matching catch, and if it is a lazy
catch, we just call the handler and do not change anything about the
dynwind list.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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