Hacker News Reader

Comment by dherman | Hacker News Reader

(TC39 and Mozilla member here.)

FWIW, this:

    For these reasons, the V8 team, along with TC39 committee members from Mozilla and Microsoft, strongly support denoting proper tail calls by special syntax.

is misrepresentative of the state of consensus and frankly premature. In particular, while I won't try to speak for all of my colleagues (we do not pre-determine an official Mozilla position in advance of standards discussion) I don't think it's the case that any of the Mozilla representatives "strongly support" syntactic tail calls, and I personally have reservations. It hasn't gotten beyond being an area of open exploration.

All that said, I'm interested to see where the explorations go, and I'm looking forward to subsequent discussions.

View on HN

Sorry for the inaccurate shorthand; maybe that should read that SpiderMonkey supports it. Eric Faust of SpiderMonkey is a co-champion of the proposal, and spoke against implicit PTC at the March 2016 TC39 meeting. It's hard to get much stronger in support of a proposal than being a champion, and Eric works for Mozilla. From that discussion, it also sounded like there was support from the Mozilla devtools team as well.

I'm interested in getting everyone's point of view. We've been discussing pros and cons at https://github.com/tc39/proposal-ptc-syntax/issues and https://github.com/tc39/ecma262/issues/535 , and it'd be great to have your input, including the overturning-prior-consensus issues you raised in committee and anything else that comes to mind.

EDIT: How do you like the new wording "For these reasons, the V8 team strongly support denoting proper tail calls by special syntax. There is a pending TC39 proposal called syntactic tail calls to specify this behavior, co-championed by committee members from Mozilla and Microsoft." ?

Yeah, I won't try to speak for Eric or the SpiderMonkey team. Maybe Eric is firmly in support of STC, but in my experience he's very good at going beyond just implementation concerns and considering all the design constraints (one of which is the cost/benefit analysis of new syntax to the user model). IMO the important question isn't who supports what but what's the best outcome. AFAICT, all three of PTC, STC, and no tail calls are on the table, but there's more hashing out to be done.

Your new wording seems totally fine -- sorry if I was pedantic, and I'm really not bent out of shape about your blog post. I just want to be sure that people don't get confused about where things stand. New features such as STC require time to bake (which is part of what the multi-stage lifecycle for proposals is all about) -- I only meant to clarify the state of the discussion.

Edit: Grrr, re-reading this it still feels like I'm speaking for Eric. He's his own guy, I should shut up about his position! All I mean to say is, I don't think anyone should be staking out strong positions at this point in syntax design. The design process is iterative and uncovers new constraints and effects, and we should all keep open minds and work collaboratively. I'm open to all possible outcomes: PTC, STC, no tail calls at all. Tricky space!

I would really be interested to know why we need a special syntax for tail calls. (genuinely curious)

I'm from Lua originally and we've had tail calls forever... why would you point them out? It should be obvious:

return wat()

I'm not on TC39, but I sit next to and work closely with people who are, and my understanding (confirmed by this article) is that the primary concern is about stack traces of existing code, specifically code with function calls in tail position.

With implicit tail call elimination, those stack traces will change in non-trivial ways that could affect debugging processes or break existing tools.

I've also heard some concerns about implementation difficulties, but I know at least one major engine has implemented PTC as specified in ES2015 without issue. I think (and hope) these concerns are secondary to the discussion about stack traces and backwards compatibility.

tl;dr: as with almost every "why is it like that" question about JavaScript, the answer is "because backwards compatibility".

(I also started with Lua and have adjusted to JS over the years; they have more in common than many people realize!)

I'm not particularly in the loop on this, though I have talked about it (idley) with a member of TC39, but my understanding is that implementation difficulties are a big part of it. SpiderMonkey and Edge both are having difficulties implementing it without hurting the performance of average code.

As the article pointed out, the ternary operator, lambdas, and &&/|| make it easy to miss a tail call. I tend to agree with you - the later will see reduced use with named arguments while optimizing for the former doesn't make much sense.

Reply on news.ycombinator.com