Re: SRFI 34

[Neil Jerram]

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
area off.

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?

Yes.

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

OK.

> 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")))
    (catch tag
           (lambda ()
             (proc (lambda (return-value)
                     (throw tag return-value))))
           (lambda (key return-value)
             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?

Thanks,
        Neil