[racket] prompts and aborts
The default prompt handler is
(lambda (abort-thunk)
(call-with-continuation-prompt abort-thunk prompt-tag #f))
When the `abort-thunk' is `(lambda () (f2))', as in `f2', then the
prompts stack up, because `f2' installs a prompt as well.
Here's an infinite loop that uses the default prompt handler:
(call-with-continuation-prompt
(letrec ([loop
(lambda ()
(abort-current-continuation (default-continuation-prompt-tag)
loop))])
loop))
At Mon, 6 Sep 2010 15:59:37 -0400, Danny Yoo wrote:
> I'm a little confused by the tail behavior I'm seeing in
> call-with-continuation-prompt and abort-current-continuation. Here's
> my test code:
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;
> #lang racket
>
> (provide (all-defined-out))
>
> (define (f)
> (call-with-continuation-prompt
> (lambda ()
> (abort-current-continuation (default-continuation-prompt-tag)
> (lambda ()
> (f))))
> (default-continuation-prompt-tag)
> (lambda (thunk)
> (thunk))))
>
> (define (f2)
> (call-with-continuation-prompt
> (lambda ()
> (abort-current-continuation (default-continuation-prompt-tag)
> (lambda ()
> (f2))))))
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
> ;;;;;;;;;;;;;;;;;
>
> (I know this is fairly useless code, but I'm using it to test my
> implementations of continuation prompts in WeScheme.)
>
>
> I expect both f and f2 to define infinite loops that consume bounded
> stack space. I expect this because, for f, the definition of
> call-with-continuation-prompt says that the handler for any aborts
> gets called in the same tail-calling context as
> call-with-continuation-prompt. For f2, I expected the same behavior.
>
> Under DrRacket 5.0.1 (as well as under regular console racket), I'm
> seeing that f has bounded memory, but f2 seems to use unbounded
> memory. Why does f2 consume memory?