Comment by slaymaker1907

5 years ago

I do think tail call optimization can make debugging/stack traces confusing if you do general TCO. In the plain single function case, TCO probably makes it easier to debug, but it can get confusing if function A calls B and then B calls C in tail position so the stack trace is just C|A. It's probably not too bad if it is just one function getting elided, but this get very difficult if multiple important calls are being removed from the stack.

This could also be a case of insufficient tooling for languages with TCO. Better support for reverse debugging would make detailed stacks less necessary. Most of the stack trace isn't that useful anyway when printing out exceptions compared to good application logging.

4 comments

slaymaker1907

spockz 5 years ago

Don’t we have debug symbols or something like it to be able to translate the optimised version into the thing you saw in code? If you need to dive into the assembly you are in for a hell of a ride anyway due to all kinds of optimisations happening.

seg_lol 5 years ago
And tail recursive functions encode their state in the args and the body. There isn't any information in the stack anyway, by definition.
If one does need to debug mutually tail recursive functions, step through them, this isn't a problem. The point is that they don't consume stack space. If you do want a stack of invocations, then don't write tail recursive code?
This style of argumentation that the GP showed should have a name.
BTW my original comment is at -1, hate but only in the tail position.
- KMag 5 years ago
  
  > There isn't any information in the stack anyway, by definition.
  This is untrue. There are 3 possibilities:
  1. Constant stack space (perhaps zero) across calls with caller-cleanup 2. Callee-cleanup 3. Caller-cleanup where an argument indicates how much stack space to clean/where to set the stack pointer
  
  1 reply →