* John Cowan [2012-03-22 14:17] writes:

> Andy Wingo scripsit:
>
>> > You could use the sequence (a c d b) i.e. evaluate the test of the cond
>> > clause in the dynamic environment of raise and unwind the stack only
>> > when the test returns true.  That's arguably "better" as this will call
>> > other handlers in the correct environment if the test returns #f.
>>
>> MHO is that this is the correct thing for r7rs to specify.
>
> Wait, wait.  Are you saying that R7RS should be in the business of
> specifying the consequences of what happens when call/cc doesn't allow
> resumption?  That's a major addition to the spec.

No. But R7RS should use full continuations sparingly; if for no other
reasons then for efficiency.  Simplifying the implementation on clunky
targets like the JVM is another reason.

> Or are you arguing for a change in the semantics of `guard` across all
> systems?  The whole point of `guard` is to supply termination-style
> behavior for exceptions.

We know now that R6RS-style guard requires full continuations.  I'm not
sure what "termination-style behavior" exactly is but it sounds like
something that should NOT use full continuations.

Therefore I think R6RS-style guard is flawed.  guard could avoid full
continuations in (at least) two ways:

1. When no cond-clause matches, guard re-raises the condition in the
   dynamic context of the guard form.  This is similar to Java's
   try-catch (+ the implicit re-throw).

2. Evaluate the cond-tests in the dynamic environment of the original
   raise.  The advantage of this strategy is that it preserves the
   context of the error; which is useful for debugging.  This is similar
   to Common Lisp's HANDLER-CASE.

I'm not arguing for a change; just noting the facts.

Helmut

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports