[racket] prompts and aborts

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Mon Sep 6 19:08:37 EDT 2010

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?



Posted on the users mailing list.