Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ES6 tail calls controversy #819

Closed
kangax opened this issue Jun 16, 2016 · 32 comments
Closed

ES6 tail calls controversy #819

kangax opened this issue Jun 16, 2016 · 32 comments

Comments

@kangax
Copy link
Owner

@kangax kangax commented Jun 16, 2016

Certain anonymous sources tell me that basically all web browsers except Safari hate es6 tail calls because they slow the rest of JS down and that folks on TC39 also absolutely hate tail calls as well.

Apparently, Chrome engineers also feel that one of the things keeping the pressure on implementing tail calls is our compatibility table.

In light of all of this, I'm asked to consider to modify the tail call entry in a table to have an asterisk saying that there isn’t a lot of support for the feature or that it's controversial or something along those lines.

I'm bringing it up here to see what ya'll think and if we can come to some kind of consensus.

/cc @ljharb @sebmarkbage

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Jun 16, 2016

Let me correct your anonymous sources a bit:

  • PTC (proper tail calls) is not the same as TCO (tail call optimization) - and in fact is NOT an optimization. PTC is in the spec, TCO is not. PTC is solely to prevent blowing the stack. So, anyone that has the expectation that it will make their code faster is very mistaken - this will rarely be the case.
  • Two browsers have no complaint about implementing tail calls. Two of them do, which is why the STC (syntactic tail calls) proposal was created, and why TC39 debated tail calls extensively at the last meeting.
  • There are certainly conflicting beliefs - among implementors, users, and among the committee - about the value of implicit tail calls vs explicit tail calls, about the importance of stack frames vs eliding them, about the performance implications, etc. However, "controversial" isn't really relevant - classes are controversial, slow things down in implementations, etc, and they don't get nor need an asterisk, because they're in the spec.
  • Perhaps this table is creating some of the PTC pressure - but much of the pressure is coming from programmers who feel that they need this feature.

At the moment, the feature is in the spec. Everyone quite simply will be building it, although there's the possibility that one or two implementors won't be able to performantly or quickly build to 100% compliance. There are indeed open questions about whether PTC will remain required by the spec, whether STC will be added, or both or neither. Until those questions are resolved, or until an implementor publicly declares that they're refusing to implement PTC, "the spec" is the arbiter of truth, and I believe there should be no differentiation on this feature from any other in the spec.

@sebmarkbage
Copy link

@sebmarkbage sebmarkbage commented Jun 16, 2016

^ GitHub won't let me heart @ljharb's comment so I'll just ❤️ it here.

@rvagg
Copy link
Contributor

@rvagg rvagg commented Jun 17, 2016

Cross-linking Node discussion about this nodejs/CTC#3

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Jun 17, 2016

I've been corrected on a few parts of my post, so I wanted to qualify some points

  • apparently 3 of the 4 major browsers have slightly differing and partially overlapping concerns about PTC. I won't go into the details because they're long and complex, but the recent meeting notes are public for anyone to study.
  • I didn't mean to imply that classes were anywhere near as controversial - in the same way, or with the same players, or with the same level of pushback from implementors - as PTC. PTC is clearly the most controversial part of ES6/ES2015; I'm just making the argument that "controversial" isn't relevant to the compat table.
  • I said "everyone quite simply will be building it" and followed up with a qualifier. To be more accurate, I think it is likely that more than one of the browsers will ship it, and that will provide enough pressure on the remaining browsers to ship it despite their individual implementation cost. Perhaps I'm wrong on that - but until that's proven in either direction, ¯_(ツ)_/¯

To sum up, I'm saying that the compat table's goal should be to represent both the spec, and defacto web standards, but not to represent current controversy or debate. The table gets updated after every TC39 meeting with the results, and I think that should continue to be the case - there's no point in marking "people are arguing about this".

@littledan
Copy link

@littledan littledan commented Jun 17, 2016

For V8's part, although we've implemented tail calls, we're not shipping them at the moment. We've heard significant concerns from users about disruptions to development/debugging flows, but we have not heard strong demand from users for the feature. We are currently trying to gather more information about the size of the impact on users which we can use to determine whether we will ship PTC. I don't think any other major browser has a PTC implementation ready to ship at this moment, so I think @ljharb's prediction is a bit premature.

At the last TC39, my impression was that there was very broad support for simply removing the PTC feature, though it did not achieve consensus at that meeting. PTC is one of the few parts of the spec represented in the Kangax table that seems like it could possibly change. ("no assignments allowed in for-in head" is another, see tc39/ecma262#260.) I don't know whether this compat table should represent things under discussion with an asterisk; a compat suite that I spend more time with, test262, does not bring active discussions into scope until they are at least at Stage 3 at TC39. I don't have an opinion about whether it should be in scope for Kangax to represent.

@sebmarkbage
Copy link

@sebmarkbage sebmarkbage commented Jun 17, 2016

@littledan I think the reason you're not seeing any demand from users is self-fulling. If they feel passionate about PTC they already use a different language to compile to JS (or a native platform). That's the people we want to join us. The only people currently affected are people that already use JS so you'll only hear from that group's minor inconvenience.

@YurySolovyov
Copy link

@YurySolovyov YurySolovyov commented Jul 26, 2016

I wonder why is issue wasn't raised while choosing features for the spec.

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Jul 26, 2016

@YurySolovyov the process for changes to the language for > ES6 is quite different than <= ES6.

@YurySolovyov
Copy link

@YurySolovyov YurySolovyov commented Jul 26, 2016

I also get a bit frustrated that discussion is on how to remove it from spec (or refuse to implement it in some other way), rather than how to actually implement it.
Did any vendor done any research concerning efficient or at least good enough implementation?
I think it would be useful to shift discourse from "We can't do it good enough, let's not do it at all" to "We can't do it ATM because of ... but let's find out how it can be possible"

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Jul 26, 2016

@YurySolovyov

@YurySolovyov
Copy link

@YurySolovyov YurySolovyov commented Jul 26, 2016

That's roughly 1.99/4, if you count WebKit Nightlies as shipped.
Is there any data from Apple about impact for real-world sites?

@craigbilner
Copy link

@craigbilner craigbilner commented Sep 26, 2016

@kangax - are the direct and mutual recursion tooltips the official benchmark for whether a platform supports PTC? I've been looking forward to this for some time now to improve my FP code but AFAICT Safari 10 is still falling over on these, some manual tests I've done and this old post. Am I missing something?

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Oct 4, 2016

I think we shouldn't change anything in the table. PTC is in the spec and it's a significant feature of ES6.

@zloirock
Copy link
Collaborator

@zloirock zloirock commented Oct 4, 2016

By my opinion, we should remove it only if and when it will be removed from the next versions of ES.

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Oct 4, 2016

@zloirock original @kangax's proposal was

to modify the tail call entry in a table to have an asterisk saying that there isn’t a lot of support for the feature or that it's controversial or something along those lines.

@zloirock
Copy link
Collaborator

@zloirock zloirock commented Oct 4, 2016

@chicoxyzzy I see. I mean we should remove it from the table if it will be removed from the spec, otherwise - leave it as is without any comments. It's not decided and now it can confuse someone.

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Oct 4, 2016

So I think we can close this because most of us agreed on keeping things unchanged.

All other discussions such as removing PTC from spec, STC and difficulties of implementation are out of scope of this repo.

@chicoxyzzy chicoxyzzy closed this Oct 4, 2016
@kylebakerio
Copy link

@kylebakerio kylebakerio commented Mar 17, 2017

link for apple's response was broken, here's the correct link:
tc39/ecma262#535

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Mar 17, 2017

@finetype thank you. Updated my comment

@hax
Copy link

@hax hax commented Apr 1, 2017

In past half year it seems still no consensus of PTC vs STC, and only webkit/safari implement PTC.

I suggest to reopen this issue. And I think we can just add a flag comment refer to this issue.

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Apr 1, 2017

@hax tail calls are in spec and our test looks fine. I think there is no reason to mention STC anywhere in the table.

@chicoxyzzy
Copy link
Collaborator

@chicoxyzzy chicoxyzzy commented Apr 1, 2017

Thinking again, we can add a note with a link. Should we? @ljharb @zloirock

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Apr 1, 2017

It would be fine to add a note, but I'm not sure I see the value in it.

@littledan
Copy link

@littledan littledan commented Apr 2, 2017

If users rely on this table to guide web development, understanding that it references what they will eventually be able to use and what browsers are converging on, a note could help clarify that we see no particular movement towards other browsers supporting PTC. OTOH maybe that's already apparent from the table's contents.

@enright
Copy link

@enright enright commented Jan 16, 2018

The arguments against implementing proper tails calls are astoundingly weak. I have to rely on Node 6 to run the asynchronous arrow code I write. This is plainly pathetic. The compat-table is doing the right thing: showing vendors who refuse to follow spec.

@gynet
Copy link

@gynet gynet commented Jan 28, 2019

It's very disappointing that a group of ppl brought up a spec (ES6) everyone was happy with but some of them are "having no plan" to implement it (silently).

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Jan 28, 2019

@gynet that should tell you that everyone wasn’t happy with it. The pre-es6 process left a lot to be desired, I’m afraid.

@YurySolovyov
Copy link

@YurySolovyov YurySolovyov commented Jan 28, 2019

It seems like it is implementable, but it may have a slightly worse DX in case of tail call, but I think someone form Apple did some statistics and not that many read-world calls are in tail position so DX damage is probably overrated.

@ljharb
Copy link
Collaborator

@ljharb ljharb commented Jan 28, 2019

If that’s the case (that it’s rare), then implicit tail calls might not have been sufficiently motivated.

@gynet
Copy link

@gynet gynet commented Jan 28, 2019

On the contrary, logically, it could be possible because es6 PTC does not get implemented by v8, ppl are not able to add code have too much TCs.

@YurySolovyov
Copy link

@YurySolovyov YurySolovyov commented Jan 28, 2019

If that’s the case (that it’s rare), then implicit tail calls might not have been sufficiently motivated.

  1. That's an argument switching. This is about if they are implementable, not whether they are sufficiently motivated. If engine claims it conforms to standard but has no PTC, then it is a lie.
  2. That's a chicken-egg problem. If people can't rely on PTC, they won't write code that uses them.
@damoco

This comment was marked as disruptive content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.