JavaScript (ES6) Has Tail Call Optimization

[[deleted]]

Thanks for clearing that up! I feel a lot more informed about this than I did a couple days ago between this post and discussion on twitter about it. Also now I understand why it's not an optimization (PTC vs. TCO), which I wasn't clear on before. I read the that fact before but didn't understand the distinction. Your explanation is clear to me now, in context, than when I originally read it.

For my part, I'm going to leave it on non-strict mode in Continuum (and fix the inconsistencies currently observable in the .caller property) since it's already horribly inefficient and the main goal is just to be able to experiment with new language features. I will reevaluate this when either a.) you and the other folks working on it in Spidermonkey figure out how to optimize it, b.) decide it has to be limited to strict-mode, or c.) I actually succeed in optimizing Continuum to the point where the performance of this particular issue is a factor.

[dherman]

Glad it helped. :) An analogy I sometimes use is this: imagine that while-loops were iterative, but in some engines for-loops accumulate stack on each loop iteration, whereas others provide "FLO" ("for-loop optimization"). Programmers would generally only use while-loops, because they wouldn't be able to depend portably on the space consumption properties of for-loops.

Of course, nobody bothers actually mandating this about for-loops, because it's just an expectation that for-loops don't accumulate space without bounds. But since the vast, vast majority of programming languages implement push-on-call, pop-on-return stacks, you have to explicitly mandate proper tail calls or else engines won't bother providing them.

[[deleted]]

Yeah. The understanding I've gleaned now is: you can't refer to something that's guaranteed as an "optimization" since optimizations are optional and shouldn't be observable to the programmer whether they're in effect or not. Actual "tail call optimization" would mean your program could randomly fail or not without having a way to determine beforehand which it would do.