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 · 25 comments

Comments

Projects
None yet
@kangax
Owner

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

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Jun 16, 2016

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage Jun 16, 2016

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

sebmarkbage commented Jun 16, 2016

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

@rvagg

This comment has been minimized.

Show comment
Hide comment
@rvagg

rvagg Jun 17, 2016

Contributor

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

Contributor

rvagg commented Jun 17, 2016

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

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Jun 17, 2016

Collaborator

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".

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan 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.

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

This comment has been minimized.

Show comment
Hide comment
@sebmarkbage

sebmarkbage 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.

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

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov Jul 26, 2016

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

YurySolovyov commented Jul 26, 2016

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

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Jul 26, 2016

Collaborator

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

Collaborator

ljharb commented Jul 26, 2016

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

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov 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"

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Jul 26, 2016

Collaborator

@YurySolovyov

Collaborator

chicoxyzzy commented Jul 26, 2016

@YurySolovyov

@YurySolovyov

This comment has been minimized.

Show comment
Hide comment
@YurySolovyov

YurySolovyov 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?

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

This comment has been minimized.

Show comment
Hide comment
@craigbilner

craigbilner 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?

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Oct 4, 2016

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@zloirock

zloirock Oct 4, 2016

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Oct 4, 2016

Collaborator

@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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@zloirock

zloirock Oct 4, 2016

Collaborator

@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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Oct 4, 2016

Collaborator

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.

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@kylebakerio

kylebakerio Mar 17, 2017

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

kylebakerio commented Mar 17, 2017

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

@chicoxyzzy

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Mar 17, 2017

Collaborator

@finetype thank you. Updated my comment

Collaborator

chicoxyzzy commented Mar 17, 2017

@finetype thank you. Updated my comment

@hax

This comment has been minimized.

Show comment
Hide comment
@hax

hax 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.

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Apr 1, 2017

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@chicoxyzzy

chicoxyzzy Apr 1, 2017

Collaborator

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

Collaborator

chicoxyzzy commented Apr 1, 2017

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

@ljharb

This comment has been minimized.

Show comment
Hide comment
@ljharb

ljharb Apr 1, 2017

Collaborator

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

Collaborator

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

This comment has been minimized.

Show comment
Hide comment
@littledan

littledan Apr 2, 2017

If users rely on this table to guide web development, unerstanding 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.

littledan commented Apr 2, 2017

If users rely on this table to guide web development, unerstanding 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

This comment has been minimized.

Show comment
Hide comment
@enright

enright 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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment