Last night I found "A Better API for First-Class Continuations", which explains how a debugger can take control and give it back to the original computation. The paper also describes the tree created by a series of continuations. Is there a way to see the whole tree? I'd like to under- stand how the backtrace command creates the stack out of the tree. You need a first error or step to show a backtrace. As the transcript below shows, a second error will change the backtrace (I had hoped it would add frames to the printout). Curiously the change is only temporary -- "undoing" the second error with ,d also undoes the change. As the second test shows, tail recursion is not involved. I assume the "change" is really an effect of the ,b printing code. Thanks! -- Derek Gambit v4.2.4
(define (a) ; a (step) in tail position doesn't cause a stop -- doubling (step) (step)) ; creates a non-tail (step) which is what the test uses (a) *** STOPPED IN a, (console)@2.9 1> ,b 0 a (console)@2:9 step 1 (interaction) (console)@3:1 (a) 1> x *** ERROR IN (console)@5.1 -- Unbound variable: x 2> ,b 0 (interaction) (console)@5:1 x 1 (interaction) (console)@3:1 (a) 2> ,d 1> ,b 0 a (console)@2:9 step 1 (interaction) (console)@3:1 (a) 1> ,q
Gambit v4.2.4
(generate-proper-tail-calls #f) (define (a) (step) (step)) (a) *** STOPPED IN a, (console)@3.9 1> ,b 0 a (console)@3:9 step 1 (interaction) (console)@4:1 (a) 1> x *** ERROR IN (console)@6.1 -- Unbound variable: x 2> ,b 0 (interaction) (console)@6:1 x 1 (interaction) (console)@4:1 (a) 2> ,d 1> ,b 0 a (console)@3:9 step 1 (interaction) (console)@4:1 (a) 1> ,q