* John Cowan [2012-03-22 23:30] writes:

> Helmut Eller scripsit:
>
>> 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.
>
> #2 is trivially simulated by using `with-exception-handler` and putting
> the cond inside the handler.  The point of `guard` is that it packages
> up the necessary escape operation.

This is not what I meant.  As I already said in to Aaron: note that I
said the "cond-tests". Only the cond-tests are evaluated in the dynamic
environment of raise; the <expression>s of the matching cond-clause are
evaluated in the dynamic environment of the guard clause.

> If I had to choose, I'd prefer #1.  Note that if there is no else clause,
> the behavior is effectively #1.

My example had no else clause, yet the behavior was not like #1.  That
example requires full continuations.

Or did you mean "if there is AN else clause"?  Then yes.

> A compiler or smart macro-expander
> could notice this and take advantage of it.

Yes, if the compiler can prove that one clause is going to match then
it can avoid full continuations.

Helmut

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