Re: Detecting endless recursion?

Lex Spoon wrote:
>
> It's not at all a troll. The tail-call optimization does make
> debugging more difficult -- please review the post again. Further,
> removing the optimization can cause programs that need it to fail, and
> thus sometimes you can end up in a situation where you cannot debug
> the program on your regular PC; you would need a computer with enough
> memory that the tail call optimization is not necessary.
>
> It would appear that there is still a solution, even in this toughest
> case, but I don't know if anyone implements it. It goes like this.
> You could have a debugging execution mode where tail calls are not
> erased immediately; instead, when the stack grows large, tail calls
> deep in the stack are coallesced to free up space. To make things
> easy, heap-allocate all activations so that you can easily delete from
> the middle of the stack. To make this nicer on the user, insert a
> marker at any location you remove stack activations, so that the
> debugger will be able to tell the truth about what has happened.


In Scheme 48, invocation frames stay around until the garbage
collector gets to them. S48 doesn't save dump images that I know of,
but it has a nice interactive debugger where you can look at frames
that haven't been garbage collected yet.


MIT/Gnu Scheme has an interactive debugger which keeps track of a
fixed number of previous calls in a ring buffer. So, if something
dies, you get thrown into the debugger and you can see what the last
hundred function calls were along with their actual parameters.


Neither of these breaks the standard's required tail-recursion
optimization.


Bear

Return to the comp.compilers page.
Search the comp.compilers archives again.