[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] 4.2.7. Exception Handling
- To: Andy Wingo <wingo@x>
- Subject: Re: [Scheme-reports] 4.2.7. Exception Handling
- From: Jim Rees <jimreesma@x>
- Date: Wed, 18 May 2011 10:50:30 -0400
- Cc: scheme-reports@x
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com> <4DD39D16.firstname.lastname@example.org> <email@example.com>
I think you're right, and I remember when implementing GUARD for my R6RS noting that it's non-trivial, and now I realize I got the re-raise part wrong. ;-) The language appears the same, replacing "dynamic environment " with "dynamic extent" for the R7 draft -- I think I prefer the former term though.
But as Alaric noted, it's possible to get it right by saving a continuation in the exception handler before jumping out for the cond clauses.
On Wed, May 18, 2011 at 10:28 AM, Andy Wingo <wingo@x>
On Wed 18 May 2011 12:19, Alaric Snell-Pym <alaric@x
> On 05/18/11 09:32, Andy Wingo wrote:
>> The docs for `guard' note that if no cond clause matches, that theAre you sure? :-) The spec notes:
>> exception is re-raised:
>> "then `raise' is re-invoked on the raised object within the dynamic
>> extent of the original call to `raise' except that the current
>> exception handler is that of the `guard' _expression_."
>> But it also notes that the exception handler's continuation and dynamic
>> context are that of the guard _expression_.
>> What does it mean to specify that the object is re-raised from the
>> original `raise' dynamic context? AFAICS there is no way to know what
>> the dynamic context is at the time of `raise', as the dynamic state is
>> unwound before invoking the handler.
> The dynamic state isn't unwound.
"That implicit `cond' _expression_ is evaluated with the continuation
and dynamic extent of the `guard' _expression_"
"The final _expression_ in a <cond> clause is in a tail context if the
`guard' _expression_ itself is."
These two sentences indicate to me that my example:
should unwind the dynamic state, and that this program:
>> (define p (make-parameter 0))
>> (define f
>> (lambda ()
>> (guard (e ((p)))
>> (parameterize ((p (+ (p) 1)))
>> (raise #t)))))
(guard (e ((zero? (p)) (f))
(define p (make-parameter 0))
(parameterize ((p 1))
should never complete (i.e., it should loop indefinitely with no
additional memory consumption).
Scheme-reports mailing list