6 ms·

Maybe it would be useful to mention that debugging can be more difficult when using tail calls as previous stack frames are not available.

• adwf 9y ago
  The general solution to that is to have a debug compiler setting to turn off TCO when debugging. Of course this leads to its own problem if your now unoptimised recursive blows the stack...
• srean 9y ago
  But isn't the whole point of tail recursion not to have those stack frames ? Iterative alternative would not have those stack frames either. I don't hear that complain for iterations or the complain that the previous version of the iteration variable has been overwritten. Tail recursions have the same thing, the 'stack variables' get overwritten. With time travelling debuggers it might be possible to look at those, but that's a whole new topic.
  • pdpi 9y ago
    > But isn't the whole point of tail recursion not to have those stack frames Sure. But a recursive function can have errors happen in one call that are only detected a few levels down. Given a full call stack, you have a trace of the execution thus far that gives you information about where, exactly, things went wrong. With TCO, you're just left with the original call at the top, and the failed state at the bottom, and no snapshot of what happened in the meanwhile.
    • srean 9y ago
      What you say is indeed true, but only partly so. The state of affairs would be no different in the corresponding iterative solution. I say 'partly' because you could put a break point at the entry point or before the call. One would be able to debug the recursion just as one would debug the corresponding loop.
• wruza 9y ago
  Debugging is already difficult since all returned stack frames are not available. Sometimes I miss softice’s trace mode (printf habit helps).