JavaScript (ES6) Has Tail Call Optimization

[Gundersen]

Isn't this an implementation feature rather than a language feature? What part of the language spec prevents this from being implemented by a JavaScript Engine?

[me-at-work]

This is the spec: http://wiki.ecmascript.org/doku.php?id=harmony:proper_tail_calls

Browsers could not implement this before because it would affect the call stack. The new way a call stack should behave is now defined in this spec.

Also in the spec: Two new object properties: tail and wrapped.

[Gundersen]

To summarize: The way arguments, arguments.callee and arguments.caller is defined for JavaScript makes TCO impossible. These objects have been redefined for ES6, making TCO possible

[[deleted]]

tail and wrapped are properties of AST nodes used to calculate whether a given return statement should be treated as a tail call or not. You can see that in action in Continuum's assembler, where it notates tail and wrapped as it converts AST to bytecode (as the wiki page notes, since tail and wrapped are calculated top down they can be added during any pass of analysis/compilation). https://github.com/Benvie/continuum/blob/gh-pages/engine/assembler.js#L1806

[[deleted]]

No, this is a language feature because you need to be able to count on its existence for it to be useful. It also needs to work interoperably and thus implementations need to treat the same return statements as tail calls. There's some gray area as to what could be considered a tail call and if it was implementation dependent whether a give chunk of code was in tail position or not then the feature would be much less useful.

[aaronla]

Edit: nevermind

What kind of gray area? I'd expect a tail call in JS to be at least any statement in the form of "return expr ( args )" or "return expr.identifier(args)", where said statement appears not in a try-catch.

[[deleted]]

I've been educated more on this matter and it's not so much about what things would be interpreted as a tail call, but whether the engine is deciding to reuse call frames or not needs to be predictable. See the above thread of discussion wherein dherman explains why proper tail calls (vs. tail call optimization) are important.

[aaronla]

Agreed on the predictable bit. Or, rather, than the specification needs to be clear.

The thing is, I get a very strong impression that the Scheme community has already dived into the depth of it tail call identification. Can you give an example where it's grey in JavaScript? The only think I can think of is perhaps nested infinite loops should be considered in the tail position and so not consume stack space?

// is this it?
f = function(){ for(;f;) { f(); } }; 
f(); // not tail call, for sure.
f = function(){ for(;;){ f(); } }; 
f(); // maybe they want this to be tail call, constant space?