Closed mcfedr closed 8 years ago
Last time I checked, tail calls are typically not optimized in Java because the JVM specification requires correct stack traces, which can be introspected at runtime.
For C, although some compilers (including GCC) have tail call optimization flags, I don't think they are in very widespread use, and definitely not standardized across implementations the way ES2015 or R5RS Scheme specifies.
Ah, I guess the C compilers are removing tail recursion, but not all tail calls, that would seem to be the difference.
I had a quick look, with -O3
GCC converts tail recursion into loops, so no stack trace is left.
Some C/C++ compilers attempt some amount of TCE, but it is extremely limited. Very few tail calls can actually be removed in C, because of the omnipresent pattern of taking the address of local variables and passing it to functions to emulate out args. As soon as a local stack address escapes like that (and the compiler can't analyse the callee), TCE is out. It's even worse in C++, where any declaration that involves a destructor prevents TCE.
Fair enough, thats interesting to know. I'll close this for now, I do think it would be a shame to add syntax for this to JS as it would reduce its usage dramatically, and it seems like it should have potential for faster and more efficient JS engines in the future.
No one has proposed prohibiting anything. The proposal is just to not guarantee the optimization.
If I write C code, or Java, the compiler will optimise out tail calls. The same issues of stacks must exist when debugging that code. Why would JS be any different?
It seems like a lot of developers would miss out on potential speed increase. Even if now its not faster in all browsers, that is likely to change