Response to the proposal to add explicit tail call syntax to ECMAScript

[msaboff]

After some discussion with other JavaScriptCore team members, we at Apple cannot support the suggested change to make tail calls explicit via syntax due to the expected web incompatibilities those changes will create.

Given that tail calls are currently part of the ES6 and draft ES7 specification, a compliant implementation should implement tail calls as described in those specifications. Compliance with any proposed changes would not occur for almost two years since the earliest that any proposed tail call changes could be adopted would be for the ES2017 (ES8?) specification. In the mean time web pages and Javascript applications will be created that are susceptible to future breakage.

In addition to the current JavaScriptCore implementation, it is likely that other browser venders will implement Tail Calls compliant with the current standard. Let’s consider the changes to tail calls as suggested at the March 2016 TC-39 meeting and the impact it would have on Safari and any other compliant implementations that will be shipped this year. I’d like to cover what I understood was being presented at the March meeting, but I will also cover two other reasonable variants of that proposal and my assessment of their suitability.

1. Tail calls based on tail position are optional. Tail calls based on opt-in syntax are required. There will be web pages and web applications developed starting this year that take advantage of tail calls as currently specified. Those web pages would become susceptible to breakage should we change the specification. Consider web pages that take advantage of tail calls as intended in the current specification. The Javascript written for such a web page assumes unlimited tail calls. Obviously, those pages won't work on an implementation that doesn’t support tail calls. If one browser decides to stop supporting implicit tail call behavior, they break that class of web pages. Therefore early adopters like us need to continue to support the currently specified behavior. The implication of this is that ES6 tail call behavior cannot be made optional without compatibility issues for Safari. Other early adopting browsers have the same issue.

   If another browser decided to not support implicit tail calls, but waits for the proposed change and only implements explicit tail calls, they introduce cross browser incompatibilities. Certainly such a browser is not compatible when running a web page that depends on implicit tail calls and likely never will be. In addition, there would be at least another class of incompatibilities. Consider a web page that inadvertently makes infinite recursive calls. For browsers that waited for explicit tail calls, that web page could throw an out of memory exception that might be silently caught, after which the web page proceeds as expected. For Safari and other browsers that support implicit tail calls, that web page is stuck in an infinite loop. The error is in the web page, but the handling of the error by each browsers is vastly different depending on their support of implicit tail calls. We have seen this type of issue in the past and reduced our stack size to maintain cross browser compatibility.

   Approval of this proposal also encourages browser vendors to wait to implement the current ES6 specified tail call behavior. This selective delay by some implementations diminishes the purpose of the ECMAScript standard and the features contained therein. Selective support by various implementations will cause developers to delay their adoption of the programming patterns tail calls was designed to address. Again this only impacts early adopting browsers like Safari.

   The main problem with this proposal is that it relaxes normative behavior and makes it optional, effectively eliminating that behavior from the standard. After we work through the early adopter problems described above, we’d introduce a new problem: Developers don’t know if they can use tail calls based on tail position or not, since implementations vary. Feature testing for the optional tail call behavior would be difficult and cumbersome, given the current specification. Optional behavior without a feature test has little place in the standard and cannot be relied upon by implementors and developers alike.

   Given these web compatibility issues and related developer concerns, we reject this type of proposal.

2. Tail calls based on tail position are forbidden. Tail calls based on opt-in syntax are required. A proposal based on this option requires that early adopting implementations, like Safari, need to change and stop supporting implicit tail calls. Those changes break web pages designed for the current spec as described above. It not only breaks those web pages, it would require that they be rewritten. The web breakage and subsequent rework by web developers caused by this option is much worse than with the first option.

   There will also be web pages that accidentally took advantage of and benefited from implicit tail calls. With this proposal, those web pages could break due to running out of stack space. These breakages would be confusing at best to the web page implementers and likely damage the perceived quality of Safari.

   Due to the breakage this imposes on Safari and web pages developed to use implicit tail calls, we also reject this type of proposal.

3. Tail calls based on tail position are required. New syntax for verifying tail position is required. This is the only proposal that wouldn’t cause breakage. This proposal would be to add syntax to signify a tail call is intended, but wouldn’t change the normative nature of tail calls as currently specified. If the call is not in tail position, a syntax error is issued. Implicit tail calls as currently defined would still be normative and must be implemented by conforming implementations. This change is backward compatible. Pages developed to take advantage of proper tail calls without the new syntax would continue to work. Javascript code developed with the new syntax get additional checking and the added benefit that tail calls appear different in the source code. The usefulness of this change is minimal though as it adds optional syntax with little corresponding semantic changes.

   We recommend against this proposal, but our objection is not as strong as our objections to (1) and (2), since this proposal would not harm web compatibility. Our main concern is that this proposal could add confusion with very little benefit.

[bterlson]

Interop is about how actual implementations match and how well they run code that exists. As far as I am aware there is no actual interop concern with regard to tail calls as tail calls are not implemented interoperably in browsers and will not be for some time. It is possible (and has occurred before) that a change to a ratified specification results in more interoperability rather than less. See for example myriad changes to functions in sloppy mode or removal of Proxy's enumerate trap (something Edge had already shipped). Can you clarify what websites that exist today or in the near future would break as a result of adopting a proposal like (1)?

An implementation can do implicit tail calls without violating the spec, though I agree developers would not choose to rely on the implicit tail calls as there is no guarantee they will work. That's exactly the case they're in today and will be until they can support only browsers that support tail calls. A syntactic sigil would actually help developers feature detect an otherwise very difficult to test for feature.

[getify]

A syntactic sigil would actually help developers feature detect

How do you propose they do that? With try..catch and Function(..) or eval(..)? What would happen if a browser landed this syntax (to support annotations of developer intent) but refused to actually optimize some tail calls for any of various reasons? Developers still wouldn't be able to rely upon the optimization, even if the syntax test passed.

My point is merely that feature-testing is a weak argument for the syntax addition, when what's already at stake here is that a standard was developed, voted upon, and began to be implemented, and then browsers started backing off from their commitments to it. I don't see how adding syntax (that we can hackily "feature test" for, at best) is going to give us developers any more reliability on PTC than we have in ES2015, which is to say, not much.

Side Note: I proposed real feature tests for stuff like this, through an API, and it was largely shot down.

I also suggested a hackish pattern for meta-programming with PTC wherein you structure your recursive code to attempt PTC recursion, but if the env kills it because of no TCO, then you just detect and restart. I had hoped this was nothing more than an interim sort of hack until PTC was guaranteed, but it sure sounds from the tone of discussion as if it may never be.

Feature-testing with syntax (that can as easily be ignored as implicit PTC) is not any more compelling to me. It won't buy me anything I don't already get with ES2015 and -- if it's call-site based instead of function-signifier based -- will make more footguns for my recursive programming, in the cases where I forget to add it.

[bterlson]

@getify let's try to keep this thread focused on Apple's objections to hearing proposals that alleviate other implementers' concerns. I've set up a GitHub repo where we can discuss the myriad other questions/issues involved. Feel free to start a new OP (I will also be opening issues to discuss some of the questions we know we have).

[wycats]

There's something I'm trying to understand about this conversation:

"Proper Tail Calls" is the feature that is included in the ES2015 spec. It specifies a list of productions and requires engines to implement those productions as tail calls.

"Tail Call Optimization" is an alternative that opportunistically implements certain productions as tail calls, but offers no guarantees about when it happens.

From the perspective of ES5, nothing is stopping an engine from implementing TCO today. The additional debuggability constraint makes implementations less willing to ship it, but that's not something the spec directly addresses.

Aside: The Ruby VM has support for TCO, but requires you to use the "VM" interface, supply an extra flag, and compile the code separately, because the Ruby core team has concerns about debuggability. Because they have implemented the feature, we know that their concern is not implementation difficulty, but rather the impact on backtraces (and that they aren't using that as a smokescreen to avoid doing work).

Here's what I'm trying to understand:

1. Since nothing is stopping JSC from implementing TCO in the absence of a spec blessing, there is no reason for JSC to revert the work, even if we completely removed PTC from JavaScript.
2. Since other browsers haven't yet implemented PTC, there is no way for a web developer to rely on the behavior when writing recursive programs.
3. There is nothing stopping Safari from making additional guarantees about PTC, so that Safari can avoid breaking developers who have come to rely on this functionality.

In addition, if we define an explicit syntax for PTC, that means that we, TC39, commit to keeping PTC in our critical path, and should avoid us regressing on engines that want to make an additional promise of PTC in the absence of an explicit opt-in.

[getify]

there is no way for a web developer to rely on the behavior when writing recursive programs.

One of my above points is that I don't believe this to necessarily be true, depending on what we may mean by "rely". If "rely" is a binary feature test, yes true. But if "rely" is "hope for" progressive enhancement optimization, not true.

In the latter sense, the snippet I linked to above suggests that (at least some) recursive code can be written to attempt PTC and assume/hope for TCO of it, but catch if the engine has to kill it for no TCO, and then restart and repeat the process. Code that falls into the non-TCO path will inevitably run slower/less efficiently, but still run. And developers can indeed rely on (hope for) -- because ES2015 promised it -- that "slower" code to get to the "faster" path eventually.

This is not just theory, I actually did exactly this awhile back. And it's my current strategy for bridging from non-TCO to TCO.

[wycats]

This is not just theory, I actually did exactly this awhile back. And it's my current strategy for bridging from non-TCO to TCO.

If at least one engine promises PTC (as Safari is doing), that's still a reasonable strategy :)

And if a lot of people use it, that will put pressure on the other engines to make the same promises. In other words, don't try to accomplish by force what we can accomplish with less risk by persuasion.

[wycats]

And it's my current strategy for bridging from non-TCO to TCO

Just so I'm sure I'm understanding, you mean PTC ("guaranteed TCO") not "more TCO in general" right?

[msaboff]

Interop is about how actual implementations match and how well they run code that exists.

This is the crux of our argument.

As far as I am aware there is no actual interop concern with regard to tail calls as tail calls are not implemented interoperably in browsers and will not be for some time. It is possible (and has occurred before) that a change to a ratified specification results in more interoperability rather than less. See for example myriad changes to functions in sloppy mode or removal of Proxy's enumerate trap (something Edge had already shipped).

Our point is that the proposed change would decrease interoperability. Some implementations will do implicit PTC and eventually all will do Syntactic Tail Calls (STC). But as @getify points out, feature testing for either difficult and kludgy at best. Adding STC complicates matters as both PTC and STC would need to be tested.

Can you clarify what websites that exist today or in the near future would break as a result of adopting a proposal like (1)?

There are no known websites that would break with proposal (1), optional PTC + future STC. There are also no known current websites that will break with ES6 PTC alone. My point is that one can easily envision a website written to take advantage of PTC that would break without them. Remember that the PTC feature was added to enable a pattern that doesn't work today. Part of the objection to (1) is that future cross browser compatibility could force WebKit/JavaScriptCore to eliminate PTC and only support STC. In the process we break websites written assuming PTC.

An implementation can do implicit tail calls without violating the spec, though I agree developers would not choose to rely on the implicit tail calls as there is no guarantee they will work. That's exactly the case they're in today and will be until they can support only browsers that support tail calls.

A spec compliant implementation would need to support PTC. Without broad support across major browsers, we introduce confusion that @getify points out.

[getify]

you mean PTC ("guaranteed TCO") not "more TCO in general" right?

Yes, sorry for the imprecise wording.

[msaboff]

@getify let's try to keep this thread focused on Apple's objections to hearing proposals that alleviate other implementers' concerns.

I think these comments are focused on our objection. Developers do not have a way to feature test support for PTC. In my opinion, the addition of STC doesn't make things better, it makes them worse.

[msaboff]

There's something I'm trying to understand about this conversation:

"Proper Tail Calls" is the feature that is included in the ES2015 spec. It specifies a list of productions and requires engines to implement those productions as tail calls.

"Tail Call Optimization" is an alternative that opportunistically implements certain productions as tail calls, but offers no guarantees about when it happens.

What we are talking about here is "Proper Tail Calls" (PTC).

In addition, if we define an explicit syntax for PTC, that means that we, TC39, commit to keeping PTC in our critical path, and should avoid us regressing on engines that want to make an additional promise of PTC in the absence of an explicit opt-in.

At that March '16 meeting, TC39 agreed to support PTC. The problem is that the adoption of STC coupled with changing PTC from normative to optional will likely necessitate that Safari and other WebKit based implementations will need to change to follow what other implementations do. If the optional behavior is only implemented by Safari, it will likely be problematic to be different than other browsers. In the process we will likely break web pages and applications written between now and then.

[wycats]

At that March '16 meeting, TC39 agreed to support PTC. The problem is that the adoption of STC coupled with changing PTC from normative to optional will likely necessitate that Safari and other WebKit based implementations will need to change to follow what other implementations do. If the optional behavior is only implemented by Safari, it will likely be problematic to be different than other browsers. In the process we will likely break web pages and applications written between now and then.

Can you explain why Safari will feel that it needs to remove an optimization (TCO) simply because it's optional, and why Safari would not be able to make a strong claim to developers that on Safari PTC is guaranteed?

[allenwb]

Before we pour too much energy into this we should remember that PTC is in the ECMAScript specification because there was consensus among all the TC39 members to included it. To remove it would require a similar consensus. Is there any chance of TC39 getting such a consensus in the short term? Based upon may recollection of the March meeting discussion and this (and related) threats we seem to be far from having a removal consensus or any other concrete proposal for changing PTC portions of the language specification.

Perhaps our energy would be better spent on helping concerned implementors understand how they can successfully (and economically) deal with the standard as it currently exists.

(and regarding optional TCO, PTC is in the spec. because we (the TC39 delegates) know that JS programmers could not interoperably depend upon optional TCO and that we could not depend upon all implementation to bother implementing such an optional feature. We know there would be implementation push back and that is why it was specified as PTC and not TCO. We should not fold on this point with the first push back. Rather we should let this play out in the market for as long as it takes to resolve itself.)

[bterlson]

I think these comments are focused on our objection. Developers do not have a way to feature test support for PTC. In my opinion, the addition of STC doesn't make things better, it makes them worse.

Sorry, I did not get that from your original post, and I was trying to keep the conversation focused. In that case, can you elaborate on how STC makes feature detection harder?

[msaboff]

Can you explain why Safari will feel that it needs to remove an optimization (TCO) simply because it's optional, and why Safari would not be able to make a strong claim to developers that on Safari PTC is guaranteed?

We are not talking about removing an optimization (TCO) we are talking about removing Proper Tail Calls (PTC). What the JavaScriptCore team has implemented is ES6 compliant PTC. Whether or not we or any web developer considers it also an optimization is moot and immaterial for this discussion.

I think I outlined in the initial post why we might feel compelled to eliminate PTC at some point after STC are implemented.

[wycats]

We are not talking about removing an optimization (TCO) we are talking about removing Proper Tail Calls (PTC).

We are talking about making TCO optional without an explicit opt-in. We are not talking about disallowing PTC.

What the JavaScriptCore team has implemented is ES6 compliant PTC.

Yes. That is true.

Whether or not we or any web developer considers it also an optimization is moot and immaterial for this discussion.

Can you please explain why JSC would feel that they need to remove their PTC implementation if other engines did not implement PTC?

Concretely, what are the interop concerns?

[msaboff]

I think these comments are focused on our objection. Developers do not have a way to feature test support for PTC. In my opinion, the addition of STC doesn't make things better, it makes them worse.

Sorry, I did not get that from your original post, and I was trying to keep the conversation focused. In that case, can you elaborate on how STC makes feature detection harder?

During various TC-39 discussion, it has been made clear the there should never be the need for feature testing Spec'ed ES normative behavior. In ES6 (and draft ES7) PTC are normative. If a future version of ES made currently normative PTC optional, then developers need a PTC feature test. That is what proposal (1) would do, add the need for a PTC feature test. About the best way to feature test for PTC is to overflow the stack and catch. Note that the kangax ES 6 compatibility webpage makes recursive calls 1 million levels deep to feature test for PTC a total of three times. The kangax method is too simplistic as a browser might increase their stack size for other reasons. Having written an out-of-stack corner case test, I can tell you it takes some time to execute and a straightforward implementation would block execution during detection. There would be a brief growth industry for developers to write the best PTC feature test. Some of these feature tests might trigger latent bugs in various browsers.

The STC proposal could be amended to include a feature test capability, but it is my sense that there wouldn't be TC-39 committee support for such an amendment. Certainly adding a PTC feature test to a future version of ES, when PTC were made optional, seems problematic and would require developer rework of ES6 compliant web applications.

As @getify points out above, having STC doesn't solve the feature test, as an implementation may implement the syntax without making a true tail call. Eval'ing some code to see if is throws a SyntaxError seems a little weird to check for the absence of a feature. Yet it may not be sufficient to indicate an implementation supports STC. To be complete one might need / want to test that both PTC and STC actually make a true tail call. All 4 combinations could exist in deployed browser implementations.

[msaboff]

We are not talking about removing an optimization (TCO) we are talking about removing Proper Tail Calls (PTC).

We are talking about making TCO optional without an explicit opt-in. We are not talking about disallowing PTC.

Let's be very clear what we are talking about here. PTC are required for ES6 compliance. Some implementations are not planning on implementing PTC. Instead they are proposing the addition of STC and make PTC optional.

Neither I nor do I think those proposing STC are talking about TCO. The ES6 spec only talks about reusing stack space.

[getify]

Just a quick clarification question (especially since I'm already guilty in this thread of imprecise wording): PTC is an optimization, right, in the sense that it prevents growth of the stack as the calls pile up? I am guilty of not really understanding the extent that TCO is different from PTC. In other words, proper tail calls, from a grammatical standpoint, seem irrelevant/pointless if they aren't implying the constant-stack-size thing on such calls, and that is the optimization I have in mind when I say TCO. So what additional optimization am I missing that TCO implies that PTC does not?

[allenwb]

@getify no PTC is not an optimization. It is instead part of the required semantics of certain calls.

An "optimization" is generally something unobservable (ie, semantic preserving) that an implementation might (ie, optionally) do to to enhance performance or some other interesting metric. That difference between PTC and TCO is that PTC is required (and observable) semantics. TCO is just an optimization (assuming that you don't consider stack overflow on unbounded recursion part of the semantics of call)

[msaboff]

Just a quick clarification question .... So what additional optimization am I missing that TCO implies that PTC does not?

Proper Tail Calls as specified in ES6 only require reusing stack space. A Tail Call Optimization might also use different instructions to make and/or return from a call. It might have different prologue / epilogue code that would eliminate the saving and restoring of registers. Argument count and type checking code might be bypassed when tail calling to the same function. A good compiler could turn a tail call to self into a loop. As @allenwb says, these are unobservable performance enhancements beyond the observable stack space reuse.

[getify]

@allenwb @msaboff thanks for the clarifications.

[bterlson]

During various TC-39 discussion, it has been made clear the there should never be the need for feature testing Spec'ed ES normative behavior

I don't believe this is true - in fact, it seems like the opposite to me. Can you elaborate or link to notes?

I still am missing something critical here, though, so please forgive me. I don't understand how feature detection with PTC is easier than with STC. Scenario: I'm a dev who wants to use either my PTC/STC-dependent algorithm or a less efficient one (possibly transpiled). Basically only option with PTC is recurse a bunch of times and look for an error, unreliable as you say. If we have STC, the situation is at most just as bad, but can be made easier by taking advantage of the fact that no one will actually ship a browser with STC syntax but without STC semantics. Testing for syntax seems like a very easy litmus test that will be valuable in practice. Thoughts?

[getify]

no one will actually ship a browser with STC syntax but without STC semantics

So you say, but I don't think there's anything that developers could actually rely on there. For example, the Mozilla folks might not want to honor a STC on a cross-realm call. AFAIK, the jury is still out on whether that case would cause an affirmative catchable error or just a warning. If it turns out to be a warning, for example, then a developer may not be able to rely on just a general feature test for STC as they'd need to check specific STC cases in tests.

Also, IIUC, a call-site may possibly not obviously look cross-realm but actually be cross-realm, so developers would have to be a lot more careful about the assumptions they make from FTs.

Bottom line, introducing STC alongside PTC would, in general, lead to the need to test both. I think that was @msaboff's point (at least I hope I got it right).

[bterlson]

In a world where Mozilla ships with just a warning, a library author that wants to feature detect the presence of STC has two options: 1, simply test syntax and not explicitly support cross realm calls (very reasonable, cross realm calls are in practice very rare today, and not something developers typically code defensively against as there are other complexities involved), or 2) do exactly what you have to do today with PTC and actually set up a cross-realm call chain and see what happens. So unless I'm missing something (probably am), at worst STC seems as bad as PTC for feature detection, but at best allows a very simple feature detection method that will in practice work for most people.

[msaboff]

During various TC-39 discussion, it has been made clear the there should never be the need for feature testing Spec'ed ES normative behavior

I don't believe this is true - in fact, it seems like the opposite to me. Can you elaborate or link to notes?

I don't know if it is in the notes, but I suggested at one point feature testing some other feature and the response was that the committee wasn't going to go back to that kind of world. Besides, normative behavior doesn't need a feature test.

I still am missing something critical here, though, so please forgive me. I don't understand how feature detection with PTC is easier than with STC. Scenario: I'm a dev who wants to use either my PTC/STC-dependent algorithm or a less efficient one (possibly transpiled). Basically only option with PTC is recurse a bunch of times and look for an error, unreliable as you say. If we have STC, the situation is at most just as bad, but can be made easier by taking advantage of the fact that no one will actually ship a browser with STC syntax but without STC semantics. Testing for syntax seems like a very easy litmus test that will be valuable in practice. Thoughts?

Feature testing for PTC or STC would be about the same if a developer wanted to make sure that each really made the tail calls they expected. Having to feature test for both and deciding what to do based on the combinations complicates things. Consider Safari version N supports PTC but not STC. Later, version N+1 supports both PTC and STC. It is likely that other browsers will support only STC. At some point, good web apps will need to check for PTC and STC, and select among three broad code paths. This seems unruly for developers. That's one way that STC makes tail call feature testing more complicated. Given this complexity, a developer decides to only checks STC syntax and drops their PTC check and corresponding path. The result is that we'll lose out for users with Safari N due to the complexity of checking and coding for both PTC and STC.

[bterlson]

Besides, normative behavior doesn't need a feature test.

Maybe we're talking about different things. Feature detection is most frequently used to detect whether an implementation supports some normative behavior so that they can, for eg., use built-in WeakMap when available, otherwise a polyfill.

I see what you are saying now about the difficulty, though! I was comparing the cost of STC by itself rather than in addition to PTC.

[rossberg]

On 13 April 2016 at 01:30, Michael Saboff notifications@github.com wrote:

We are not talking about removing an optimization (TCO) we are talking about removing Proper Tail Calls (PTC).

We are talking about making TCO optional without an explicit opt-in. We are not talking about disallowing PTC.

Let's be very clear what we are talking about here. PTC are required for ES6 compliance. Some implementations are not planning on implementing PTC. Instead they are proposing the addition of STC and make PTC optional.

Note that TC39 agreed to adopt the "train model", or the "living spec". That is, we continuously improve the spec, and only put stamps on it once a year, mainly for bureaucratic reasons.

One side effect of this is that we do not do errata anymore. If we find problems with a version of the spec, we just fix it in the next one. We have done so before, see e.g. the changes around proxies or local functions.

In the old world, we might have put changes like the one under discussion into the erratum category, but we got rid of that device, under the assumption that everybody agreed to the above model.

I don't see the interop issue or any complication with feature testing if we replace PTC with STC -- quite the opposite, in fact. The only way we could practically get into a situation is if some browser shipped a semantics before we have resolved this discussion. That's why Chrome has pulled PTC from v51, although it was ready.

@allenwb, agreed with your description of the past, but as we all know, the ES6 proposal process was utterly inadequate. By the current process, several of the features in the current spec (and that includes tail calls) would barely be at stage 3. So I think there is no shame in taking some liberty to revisit some of the decisions where it is not too late.

[getify]

@rossberg-chromium There is already production code (which I wrote) that is expecting eventually for PTC to "optimize" (aka improve the efficiency of) it. If I thought of that adaptive pattern (see above), there's a chance others have too, and I imagine it would be difficult to find in code searches. This is not a zero-cost change to revisit and do away with PTC in favor of STC more than a year after the spec was finalized.

A change from PTC to STC means that one cannot feasibly write adaptive recursive code the way I've suggested that merely progressively enhances once a browser lands the support. It means that the code in question absolutely has to be changed (and I'm not on that project anymore). Either that code path will have to be forked, with some sort of hard feature-test to select the STC or the non-recursive, or it has to be made entirely un-recursive until some magical future date when all supported browsers have STC.

That is a much less friendly path to migration to tail calls. If your usual "cost models" only involve looking at existing deployed code that will break, I would suggest you also have to consider the additional migration cost of syntax-annotated versus implied "optimization".

[bterlson]

I don't see the interop issue or any complication with feature testing if we replace PTC with STC -- quite the opposite, in fact. The only way we could practically get into a situation is if some browser shipped a semantics before we have resolved this discussion.

Yeah that's the part I was having trouble understanding as well. @msaboff is Safari shipping imminently with PTC enabled?

[bterlson]

There is already production code (which I wrote) that is expecting eventually for PTC to "optimize" (aka improve the efficiency of) it

Part of the motivation for me to re-examine this issue is the perception that PTC makes your code faster, the fact that much code exists that happens to include tail calls, and the fact that Chakra isn't sure yet how we can implement tail calls without regressing performance of function calls and effectively de-optimizing your program (which, presumably, doesn't care about the main benefit of PTC of avoiding stack growth since it runs fine without PTC).

[getify]

Part of the motivation for me to re-examine this issue is the perception that PTC makes your code faster,

Make sure that you are doing an apples-to-apples comparison in that analysis. The comparison should include whether your implemented PTC would be slower, equal to, or faster (my strong intuition) than the try..catch based adaptive version I've suggested. It's not just whether a normal simple recursive program gets faster if PTC is in place, but whether code that runs fully and correctly, even to millions of call levels, in a non-PTC'd way, gets any faster if PTC is in place.

Also, "faster" is not the only concern. Memory efficiency/churn is also a strong motivating factor.

[msaboff]

@msaboff is Safari shipping imminently with PTC enabled?

Safari will ship PTC as part of the next release. I cannot comment on the schedule of that release.

[littledan]

I'm not sure which browsers the OP is concerned about compatibility with. The only browsers which seemed to ship TCO turned on are Safari Tech Preview 1, and some previous Chrome Canary versions, though not the current one. It would be surprising if someone published a website which worked only on those, and not in any browser in a stable release version. We're just talking about compatibility with future Safari releases, and code which expected ES2015 to be implemented unchanged (which will not happen)?

@msaboff, we have co-championed a proposal to observably change the ES2015 RegExp semantics in a couple ways. In theory, someone could have created a website which depends on the exact ES2015 semantics. However, web compatibility has to be evaluated pragmatically--in this case, it was the ES2015 semantics which were web-incompatible, even though the spec had been ratified.

Similarly, it seems that proper tail calls cannot be implemented across browsers in a completely correct way, or meeting user performance and debugging needs, so I'd say it belongs in the same bucket of the small set of things that we need to revisit from ES2015. This is not an unboundedly large set, as Chrome, for one, ships all other major ES2015 features in the current Canary.

[concavelenz]

Here are my thoughts:

• PTC are contentious (I'm curious how consensus was originally reached without an implementation proof)
• the committee should consider declaring a misstep and moving PTC back to a stage three proposal (and encouraging vendors not to implement it the ES6 semantics)
• Explicit syntax doesn't help with the problems that arise with using PTC, it just postponed and slows down adoption so we don't notice it.
• Explicit syntax does help folk that want to prevent the information loss associated with PTC and resulting debugging/error reporting issues as the explicit syntax makes it possible to ban.

If I'm understanding is correct and the main contention is postmortem debugging (node core dumps, stack trace reports from the field), then:

• If there is a solution for postmortem debugging and error reporting (which is critical for certain node.js and wide reaching web applications), then PTC can move forward as spec'd
• If there is not a solution for postmortem debugging, then even explicit syntax need to be carefully considered, but it may be reasonable for move forward with it.

On Wed, Apr 13, 2016 at 9:21 AM, littledan notifications@github.com wrote:

I'm not sure which browsers the OP is concerned about compatibility with. The only browsers which seemed to ship TCO turned on are Safari Tech Preview 1, and some previous Chrome Canary versions, though not the current one. It would be surprising if someone published a website which worked only on those, and not in any browser in a stable release version. We're just talking about compatibility with future Safari releases, and code which expected ES2015 to be implemented unchanged (which will not happen)?

@msaboff https://github.com/msaboff, we have co-championed a proposal to observably change the ES2015 RegExp semantics in a couple ways. In theory, someone could have created a website which depends on the exact ES2015 semantics. However, web compatibility has to be evaluated pragmatically--in this case, it was the ES2015 semantics which were web-incompatible, even though the spec had been ratified.

Similarly, it seems that proper tail calls cannot be implemented across browsers in a completely correct way, or meeting user performance and debugging needs, so I'd say it belongs in the same bucket of the small set of things that we need to revisit from ES2015. This is not an unboundedly large set, as Chrome, for one, ships all other major ES2015 features in the current Canary.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/tc39/ecma262/issues/535#issuecomment-209530230

[geoffreygaren]

Since other browsers haven't yet implemented PTC, there is no way for a web developer to rely on the behavior when writing recursive programs.

An important point of clarification here: Though some developers deploy to the web and test their code across all major web browsers, not all do. Developers who write WebKit-specific code -- for app-embedded content or for purpose-specific websites -- will adopt PTC, intentionally or accidentally, even if PTC code wouldn't work in some major web browsers. A change away form PTC will break that code.

We think it should be a goal of the standard's evolution to avoid knowingly breaking existing standards-based code.

There is nothing stopping Safari from making additional guarantees about PTC, so that Safari can avoid breaking developers who have come to rely on this functionality.

Michael already described a few ways in which PTC support can break a website that was tested against a browser that didn't have PTC support. So, it is only safe to support PTC if the standard encourages consistent PTC support across implementations.

[msaboff]

@littledan we are talking about web breakage between when Safari is released with PTC and some future point when STC are added and PTC become optional.

I'd like to bring this conversation back on topic. The verbal proposal made at the March TC-39 meeting was to add STC and make PTC optional. Recent posts on this thread are now talking about replacing PTC with STC. When I asked at the March meeting the PTC will always be allowed, I was assured that would be the case. Therefore the incompatibilities I present above are valid.

[littledan]

@geoffreygaren Although this is true in theory, I think we need to do this compatibility assessment pragmatically. Today, a developer would have to have to develop and test their website only in Safari Technology Preview 1 to encounter this issue, and their page would be broken in all major browser versions.

There's a lot of different threads of discussion here. What would you all think about splitting it up per topic? I opened up a bug in the tc39/proposal-ptc-syntax repository to discuss web compatibility concerns: https://github.com/tc39/proposal-ptc-syntax/issues/3 . For the appropriateness of revisiting proper tail calls for the cross-realm case, could we discuss it at https://github.com/tc39/ecma262/pull/508 , which is where the proposal lives?

[geoffreygaren]

Although this is true in theory, I think we need to do this compatibility assessment pragmatically. Today, a developer would have to have to develop and test their website only in Safari Technology Preview 1 to encounter this issue, and their page would be broken in all major browser versions.

I guess there's an implicit assumption of timeframe in this discussion. Let me make it explicit.

If we assume that a new consensus emerges against PTC, and the standard changes to eliminate PTC, and we assume that all this happens in time for Safari to eliminate PTC before shipping, then sure, there's no compatibility concern to eliminating PTC.

On the other hand, if consensus and standards change takes time, and Safari or another implementation ships PTC, then there's a compatibility concern to eliminating PTC.

I think Michael's primary point above is that options (1) and (2) have compatibility problems in a world where Safari ships PTC.

[ljharb]

It seems that this very discussion should be a reason for Safari to immediately and preemptively change whatever flag is needed to ensure that PTC doesn't ship, at least until this is resolved. What's another few months or a year when it could ensure no web compatibility problems?

[littledan]

Re consensus emerging: At TC39 in the March 2016 meeting, it felt to me like there was broad support from most committee members on making PTC based on explicit syntax. Apple opposed it for several reasons; the only other opposition I recall from other committee members was on hesitation to overturn past consensus and the need to follow the right procedure for such a move, based on a well-articulated, concrete proposal.

[geoffreygaren]

It seems that this very discussion should be a reason for Safari to immediately and preemptively change whatever flag is needed to ensure that PTC doesn't ship, at least until this is resolved.

I don't see anything in this discussion that provides a compelling or likely alternative to PTC.

What's another few months or a year when it could ensure no web compatibility problems?

We don't consider it acceptable to wait months or years to implement important new web standards.

[msaboff]

It seems that this very discussion should be a reason for Safari to immediately and preemptively change whatever flag is needed to ensure that PTC doesn't ship, at least until this is resolved. What's another few months or a year when it could ensure no web compatibility problems?

I disagree. Of course you'd expect that since I'm on the other side of the discussion 😉 What you're talking about is postponing an approved feature (PTC) in the standard because some think there may be a future concrete proposal (STC) that doesn't have the issues raised by those same people. Until there is a concrete proposal with TC-39 consensus, no implementer should be asked to stop implementing the standard.

The ES standard exists, as do all standards, so that implementers and users of the standard can progress with new capabilities at the same time allowing for interoperability. In good faith, we the WebKit team, implemented PTC as described in the ES6 standard. We did this in part because it was in the standard and because we thought it would benefit developers and users.

Since implementing it, other implementers have raised three concerns that we are aware of:

1. Implementing PTC will hurt performance.

   As far as I know this is the concern of one implementer and I believe they haven't started implementing PTC. In our implementation, we did not find performance regressions. I haven't heard anything from the Chrome implementers that they have performance concerns. So we have one and possibly two implementations where performance isn't an issue with PTC implementations. There are also many other compilers that implement tail calls, e.g. gcc, clang, Microsoft VC++, etc, that do so specifically because it is a performance improvement.

2. Because PTC elide stack frames, debugging would be more difficult.

   We know of no developers that have this concern, only implementors. Saying that we later decided that it would be more friendly to developers if they could see and interact with the elided call frames. Therefore we implemented a shadow stack that is used while ES code is being debugged. So there exists at least one implemented solution to this concern.

3. Because PTC elide stack frames, telemetry involving Error.stack will break.

   The WebKit PTC implementation has been checked in for at least 6 months. For a couple of weeks, the first Safari Technology Preview has been made available. We have no reports of Error.stack issues. The Safari team encourages willing users to try the Technology Previews. If anyone can provide a website that breaks, we'd be very interested in knowing. We're willing to be the guinea pig here for other implementations to see if this is a web compatibility issue. Actual web pages that fail would be greatly appreciated, we want to improve our browser!

   I'd like to add, that comparing a known stack, Sk, collected generated without PTC, with a telemetry provided stack, St, collected on an implementation with PTC seems straightforward. If St is an ordered subset of Sk, then the stacks can be considered equivalent. Those of us who have to deal with native code stacks provided by telemetry are able to handle them with little difficulty.

At this point, there seems to be opinions that these are issues. As I see it, there is lack of data to convince me that these are valid issues. Even if they are, there are known implementations or solutions to address each issue.

[bterlson]

While we have not implemented PTC, we do not need to actually go through the work of implementing the entire feature to find that there are performance issues for our implementation. Please take a look, happy to hear any ideas you guys have (that hopefully doesn't involve months of re-engineering effort :-P).

Anecdotally, I have talked to developers who are concerned about elided stack frames, but you are right it can be solved at least with the dev tools open.

I don't find the argument that production services can change their stack bucketing code to handle tail calls compelling. That's true of any compat issue I think?

[rossberg]

On 13 April 2016 at 23:54, Michael Saboff notifications@github.com wrote:

It seems that this very discussion should be a reason for Safari to immediately and preemptively change whatever flag is needed to ensure that PTC doesn't ship, at least until this is resolved. What's another few months or a year when it could ensure no web compatibility problems?

I disagree. Of course you'd expect that since I'm on the other side of the discussion 😉 What you're talking about is postponing an approved feature (PTC) in the standard because some think there may be a future concrete proposal (STC) that doesn't have the issues raised by those same people. Until there is a concrete proposal with TC-39 consensus, no implementer should be asked to stop implementing the standard.

I agree that dragging this discussion along for months is not an option. As a kind of erratum we need to resolve it ASAP. Chrome also wants to ship their tail calls implementation. That is, we need an answer in the May meeting.

If we have a stable proposal and a working implementation in time before the meeting, and manage to agree on it and fast-forward it to, say, stage 2 (or even 3) at the the meeting, would that be in time for Apple to implement it in their next release? V8 would be willing to make the effort of doing the prototype implementation.

Since implementing it, other implementers have raised three concerns that

we are aware of:

1.

Implementing PTC will hurt performance.

As far as I know this is the concern of one implementer and I believe they haven't started implementing PTC. In our implementation, we did not find performance regressions. I haven't heard anything from the Chrome implementers that they have performance concerns. So we have one and possibly two implementations where performance isn't an issue with PTC implementations. There are also many other compilers that implement tail calls, e.g. gcc, clang, Microsoft VC++, etc, that do so specifically because it is a performance improvement.

We have seen actual performance regressions after implementing PTC. However, they have been less serious than we expected, and mostly irrelevant on practical code. But you can get 5% or more on micro benchmarks.

1.

Because PTC elide stack frames, debugging would be more difficult.

We know of no developers that have this concern, only implementors. Saying that we later decided that it would be more friendly to developers if they could see and interact with the elided call frames. Therefore we implemented a shadow stack that is used while ES code is being debugged. So there exists at least one implemented solution to this concern.

We have heard this concern from various sides, and the Chrome DevTools team is extremely worried about it. We don't think that a shadow stack is a particularly satisfying solution, since it is necessarily a best effort approach and thus incomplete. It also adds even more overhead.

[hashseed]

If I understood correctly, JSC's shadow stack is only collected when debugging (Devtools being opened), so it adds no overhead to usual execution, but also does not solve the issue with Error.stack. Is my understanding correct?

[saambarati]

@hashseed Yes.

[othermaciej]

Is anyone supporting the #2 option in msaboff's list, making PTC forbidden? Some of the comments seem to be based on assuming that is ruled out.

It seems strange for a spec to forbid an optimization, and I am likewise confused by those who suggest it should be pulled from Safari.

Since we have an existence proof of solving the performance and debuggability problems in JSC (with significant but not absurd engineering effort), the objections on those grounds seem to come down to "it's hard" or "it's too much work". Given the significant resources invested in improving JS engines in other ways, that does not seem like a very good basis for changing the spec.

STC does not really solve the debuggability problem, you probably still need shadow stacks or something similar. And for the performance issue, it seems like a the wrong tradeoff to ask authors to add extra syntax to their code, to save a few months of work for VM engineers.

[s3ththompson]

STC does not really solve the debuggability problem, you probably still need shadow stacks or something similar.

The specific concern on the developer experience side is that PTC affects existing code, thus debuggability could be a regression for certain developers whose code currently has tails calls (but weren't expecting stack frame elision). In a world with explicit syntax, developers who "opt-in" to PTC with the syntax would be much more likely to understand the feature (and its effect on the stack) and be able to work around debugging issues.

In fact, the benefit of explicit tail calls is that tools can always show a "true" view of the stack; developers who don't opt-in to PTC can have easier-to-understand stack traces (and keep existing debugging behavior) and developers who do want PTC can see that frames were elided and verify that PTC is working correctly.

Since we have an existence proof of solving the performance and debuggability problems in JSC (with significant but not absurd engineering effort), the objections on those grounds seem to come down to "it's hard" or "it's too much work".

It's very hard to assert objectivity or understand motivations completely in a thread like this given the obvious invested interests in shipping PTC (and ES2015) as soon as possible. However, I would like to underscore that for Chrome this has little to do with how much work a certain implementation will be (provided basic feasibility, that is) and everything to do with ensuring that we make the right tradeoffs between developer experience, performance-by-default, and web compat--regardless of whether we're talking about something which has already been ratified and will require new consensus or whether we're talking about a totally greenfield, experimental new feature. This stuff sticks around for a long time and the details matter.

[msaboff]

There hasn't been much discussion here. There is a new pull request for Syntactic Tail Calls (STC).

At this point, there is no reason to support Syntactic Tail Calls given that the three concerns I listed above have not been refuted with provable facts. Here is my understanding of these three concerns.

1. Performance concerns of PTC.

   We now have two implementations that do not see a general performance degradation. As part of the Implement Proper Tail Call [Discussion], there was some discussion that the calling convention implemented in Chakra would require months to change their calling convention to address performance concerns. The JSC team also had to make calling convention changes to implement PTC. Those changes were at least half the effort.

   Performance concerns of specific implementations have not been nor should be a criteria for removing or changing a feature in the standard. It seems to me the appropriate time to raise a general or implementation specific performance concern is when a feature is being considered for a new version of the standard. As implementors add new features called out in the current or future ES versions, they often need to make specific optimizations to maintain current performance. Sometimes the new features cannot be added without a performance loss. That has been our experience on the JSC team.

   As @othermaciej pointed out, STC will not solve any performance issue. Instead it puts the onus on the web developer to decorate calls already in tail position. At best this will delay an implementation from optimizing for Tail Calls. When STC become prominent, all implementations will likely optimize to remain competitive.

2. Because PTC elide stack frames, debugging would be more difficult.

   PTC debug tools discussion on this and other thread express concerns that ECMAScript developers will struggle with PTC due to calls being elided. The JSC doesn't share this concern as there are techniques to include the elided frames. At least two methods have been suggested, keeping a side stack when debugging and the other is turning off PTC when debugging. There may be other methods an implementation could employ to alleviate this concern. At this point, I consider this concern closed.

3. PTC will eliminate stack frame from telemetry data.

   This issue seems to be the most common concern among participants in the PTC discussion. The PTC implementation in JSC has been implemented since October of 2015. Since that time, we have tested PTC internally as well as making the implementation available via WebKit Nightlies, and the Safari Technology Preview. We have received only one bug report related to PTC. That bug turned out to be a locking bug (trying to recursively lock an non-recursive lock) that was triggered by PTC.

   It would be helpful if there was a real example of this concern that could be demonstrated with either the Safari Technology Preview, or if PTC can be turned on in the latest Chrome Canary, via that browser. Should PTC compatibility issues come up, proper analysis of those issues should ensue and be dealt with at that time.

Given these issue lack factual support, I and the rest of the members of the Apple JSC team cannot support the suggested STC changes. I believe that are efforts should be focused on communicating the benefits of PTCs, how to use them, and the minor changes web developers will notice.