Bug? `raise` may not fully implement the intended R6RS semantics

[mnieper]

The expression

(call/cc
    (lambda (k)
      (define p (make-thread-parameter 'outer))
      (define v #f)
      (with-exception-handler
          (lambda (obj)
            (if (non-continuable-violation? obj)
                (k (list v (p)))
                (raise-continuable obj)))
        (lambda ()
          (with-exception-handler
              (lambda (obj)
                (if (eqv? obj 42)
                    (set! v (p))
                    (raise-continuable obj)))
            (lambda ()
              (parameterize ((p 'inner))
                (raise 42))))))))

is evaluated to (inner inner) by Chez Scheme. The first "inner" comes from evaluating (p) in the inner exception handler that is invoked by (raise 42). This is correct by R6RS because the handler is called with the same dynamic environment (except for changes in the handler stack) as the call to raise. As the exception handler returns, raise now raises an exception with condition type &non-continuable. This is intercepted by the outer exception handler, which evaluates (p) again, this time producing the second "inner" in the case of Chez's implementation. However, by R6RS, the "non-continuable" exception should be raised in the dynamic environment of the (inner) handler where the value of the parameter p is outer.

[mnieper]

After having re-read the R6RS, this is probably not a bug. The relevant phrase in R6RS is "raised in the same dynamic environment as the handler". As a Scheme object (the handler in this case) has no dynamic environment, it is not entirely clear what this means. In the post above, I interpreted this as the dynamic environment of the continuation where the handler was installed (which is the dynamic environment of the expression evaluating to the handler). However, if one interprets this as the dynamic environment of the continuation of the earlier call to the handler, one gets Chez's current behaviour.

The former interpretation is more costly to implement because with-exception-handler would have to capture the current continuation, and it would have to be recorded in the exception handler stack. Thus it is probably best to leave the behaviour as is and clarify the meaning of the phrase in a revised version of R6RS.

I am editing the subject line of the issue accordingly.