| > TCO only addresses recursion that can easily be replaced by a loop This is fundamentally false. TCO addresses recursion that is implemented through the arbitrarily complex composition of functions, enabling one to define arbitrarily complex loop constructs through function composition. There are many such interesting compositions that cannot be “unrolled” into a single high-level imperative for loop without essentially having to rewrite the code of all the functions being composed, including code that controls looping in interesting ways (e.g. automatically terminating on error, collecting all errors, parallelizing execution, etc.) > It is an exception from the general mental model of how function calls work It’s not, though — unless you have an incorrect mental model of how function calls work. When calling a function, the return address is first pushed on the stack (or on some architectures, stored in a link register). The target function returns from execution by popping the return address from the stack (or reading it from a link register), and jumping to that address. When calling a function, if the call is in a tail position, the calling function can provide it’s original return address, and then jump to the target function it’s calling. That’s how functions actually work. That’s the mental model. > makes tooling much more complex What significant complexity does TCO add to tooling, exactly? > the alternative is just writing a loop That’s simply not true. See first paragraph above. |
You're arguing semantics, sure, you cannot mechanically transform code which relies on TCO into a loop. That is not the same as the parents point that TCO functions are isomorphic to loops. In a language without TCO you wouldn't ever find yourself in mess of composition of functions.