[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SRFI 34
Re: SRFI 34
07 Mar 2004 18:34:37 +0000
Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
This is a thread from May 2003 that I never resolved. I've revisited
it now because of Andreas Rottman's work on SRFI 35 (conditions),
which makes me think that it would be worthwhile finishing this whole
Marius Vollmer <address@hidden> writes:
> Neil Jerram <address@hidden> 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.
I believe the docs are already correct on this point. Try `i
lazy-catch' in the manual.
> > 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.
OK, but we need to be careful to preserve the behavior of existing
code that uses `catch' to catch errors. Did you have a specific
scheme in mind here? Here's what I think might work:
- `error' and libguile errors are rewritten to use `raise' and an
appropriate SRFI-35 condition object.
- The default SRFI-34 exception handler maps the condition object back
to a key + arg list, and calls `throw' with that key and args.
> 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'.
Agreed. (I glossed over this before, because (i) SRFI-34 doesn't
provide any examples that test the difference, and (ii) my
implementation was only a quick first attempt.)
> 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.
OK, but for this I have 2 technical queries.
1. To minimize changes between the official SRFI 34 code and Guile's
version, it would be nice to introduce
call-with-escape-continuation (implemented using throw and catch)
and just replace the call-with-current-continuation's in the SRFI
34 code by call-with-escape-continuation. Is the following a good
definition of call-with-escape-continuation?
(define (call-with-escape-continuation proc)
(let ((tag (make-symbol "call-with-escape-continuation")))
(proc (lambda (return-value)
(throw tag return-value))))
(lambda (key return-value)
2. Are the define-syntax forms in SRFI-34 OK as they are, or should
they be translated (for Guile) to macro definitions?
|[Prev in Thread]
||[Next in Thread]|
- Re: SRFI 34,
Neil Jerram <=