>>50
What about sticking your backtrace into a ring buffer?
And then you write a tail-recursive iteration over some long enough list that crashes at the end, having evicted all useful information from the ring buffer.
Or, you discover that your program blows the heap because some objects that must be long dead are still referenced from your circular buffer. What's more, the behaviour depends on the interpreter settings and isn't under your control.
The root problem is that the idea of TCO that is kind of not always TCO is based on the thoroughly rotten foundation. In fact, the idea of implicit TCO is based on the same rotten foundation as well.
The primary requirement for the core of your programming platform is comprehensibility and predictability. You can have a fuzzy understanding of how exactly some particular library works, but the language itself must be simple, transparent and predictable enough for you to have a fairly accurate mental model of it. Of everything about it, from the parsing (I hope that Perl is
not going to die completely and will remain as an example of where the DWIM school of thought leads, for the generations to come) to the memory management. The more important some aspect is, the simpler conceptually it should be, and the more explicit expression it should require whenever the misunderstood intent may lead to a disastrous failure.
TCO itself is deeply flawed in this respect. It is not at all obvious when a call is in the tail position, if you consider more dense coding styles. Can you explain why
foldr (+) 0 [1..1000000] stackoverflows? I mean, it doesn't stackoverflow in the foldr itself, stack overflow happens when the expression it constructs is forced, but why is the evaluation not TCO'd?
But it gets much worse when someone tries to invent a stacktrace compression scheme. We had a compiler trying to read the implicit intent of the programmer from his code, but fair enough, at least it more or less depends on the code, if only in an obscure and non-obvious way. Now the algorithm has to read the intent directly from the programmer's mind, because there are no clues whatsoever in the code for whether this or that stackframe is better saved, while some other can safely be discarded!
And it's not something unimportant, some pleasant addition that we can make without, no, when you are in the situation when you see a stacktrace, you are already knee-deep in shit (especially if the stacktrace was mailed to you from an office on the other continent and no, they absolutely can't provide the raw data), and the last thing you want at the moment is to discover that the "clever compiler" did in fact read your mind wrong, performing TCO where you didn't need it at all and discarding the relevant information.