On 05/20/11 10:12, Andy Wingo wrote:
> On Wed 18 May 2011 21:03, John Cowan <cowan@mercury.ccil.org> 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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports