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