* 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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
