On 05/20/11 10:12, Andy Wingo wrote: > On Wed 18 May 2011 21:03, John Cowan <[email protected]> writes: > >>> "That implicit `cond' expression is evaluated with the continuation >>> and dynamic extent of the `guard' expression" >> >> The idea is that "guard" installs a handler which first unwinds and then >> evaluates the cond, rewinding if it doesn't find an appropriate clause. >> This provides termination semantics in the style of C++, Java, C#, etc. >> but with the possibility of carrying on if the guard gets something it >> doesn't expect. If you want instead to get control in the scope of the >> raiser, don't use "guard" but rather "with-exception-handler" to install >> your own handler.
Ah yes, "with-exception-handler". I was sure I remembered language that handlers are run in the dynamic environment of the "raise" but with the current handler set to the previous one in case they re-throw... It seems like "guard" changes that and I didn't notice (I just thought of it as a nice combination of "with-exception-handler" and "cond"). I'd rather prefer "guard" to not unwind, too. Why unwind and rewind? Decide whether you need to unwind, and then do so if you need to, and don't if you don't. > Andy ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
