Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo (18 May 2011 14:29 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Alaric Snell-Pym (18 May 2011 14:40 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo (18 May 2011 15:15 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Jim Rees (18 May 2011 16:22 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Jim Rees (18 May 2011 16:58 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo (18 May 2011 17:35 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling John Cowan (18 May 2011 19:04 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling John Cowan (18 May 2011 19:03 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo (20 May 2011 10:46 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Aaron W. Hsu (20 May 2011 17:02 UTC)
Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo (20 May 2011 17:17 UTC)

Re: [Scheme-reports] 4.2.7. Exception Handling Andy Wingo 18 May 2011 14:28 UTC

Hi Alaric,

On Wed 18 May 2011 12:19, Alaric Snell-Pym <alaric@snell-pym.org.uk> writes:

> On 05/18/11 09:32, Andy Wingo wrote:
>> The docs for `guard' note that if no cond clause matches, that the
>> 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.

Are you sure? :-)  The spec notes:

  "That implicit `cond' expression is evaluated with the continuation
  and dynamic extent of the `guard' expression"

and

  "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:

>>    (define p (make-parameter 0))
>>    (define f
>>      (lambda ()
>>        (guard (e ((p)))
>>          (parameterize ((p (+ (p) 1)))
>>            (raise #t)))))

should unwind the dynamic state, and that this program:

  (define p (make-parameter 0))
  (define f
    (lambda ()
      (guard (e ((zero? (p)) (f))
                (else (p)))
        (parameterize ((p 1))
          (raise #t)))))

should never complete (i.e., it should loop indefinitely with no
additional memory consumption).

Andy
--
http://wingolog.org/

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