3 ms·
> There's many valid reasons not to support TCO. The first one that comes to mind: it makes generating stack traces more difficult. > Another reason: the JVM d
by gioele 15y ago
> There's many valid reasons not to support TCO. The first one that comes to mind: it makes generating stack traces more difficult.
> Another reason: the JVM doesn't natively support TCO. This means to implement it you'll either need to use a trampoline (e.g. Erjang) or convert recursion to iteration (e.g. Clojure)
So you avoid a 35 years old functionality that makes many procedures smaller, faster and more understandable just to make the compilers simpler?
Isn't this one of the usual tradeoffs where you (should) prefer having the compiler doing the boring and dirty job of converting a recursion to a loop, with all the bookkeeping of maintaining the state and making it thread-safe, simplifying the life of the application programmer at the expenses of the compiler programmer?