proposal-ptc-syntax VS spec

The proposal of "syntactic tail calls" to provide an explicit syntax for tail calls, co-championed by committee members from Mozilla (responsible for SpiderMonkey, the engine of Firefox) and Microsoft, was a response to these concerns. However, this proposal is now listed among the TC39's inactive proposals, possibly due to diminished interest, which may stem from the infrequent use of tail recursive functions in JavaScript.

This is not actually about Tail Call Optimisation, which is more flexible and optional matter of optimisation, but about Proper Tail Calls, which are actually part of the ECMAScript 6 specification (over implementer objections)—in strict mode, calls in tail position must not create additional stack frames. This is the last piece of ECMAScript 6 that most engines haven’t implemented, because it’s rather controversial: it actually causes some performance problems, and makes debugging harder, and may have security issues (in 2016, Mozilla declared it impossible to implement across realm boundaries due to their security model).

https://github.com/tc39/proposal-ptc-syntax has a lot of useful information about it all, and a proposal to make it explicit in syntax, such as with `return continue …`.

(Fun terminology problems here. The term TCO is commonly used for PTC, and PTC is very close to being a subset of TCO, but the mandatory stack frame elision which ruins debugging feels to me like it falls outside of TCO. In various situations, debuggers will mark things like “stack frame omitted” when they’ve optimised one out of existence, but you can generally compile things differently, or something like that, to prevent this. But with PTC, it feels like the engine is kinda not even allowed to know that a stack frames may be absent. So I say PTC and TCO are a little distinct, though PTC is mostly just a subset of TCO. Reminds me of the terminology of tree-shaking versus dead code removal—where the former is essentially a subset of the latter, but that the effects are just slightly different, though I’d say it’s more slight in that case than this.)

4. Proposed something else [ https://github.com/tc39/proposal-ptc-syntax ]

While apple is against Syntactic tail calls, they’re mainly just opposed to versions of it that would remove/unrequire the tail-call optimisation they already do: https://github.com/tc39/ecma262/issues/535

For the version of it that is backwards compatible, they wouldn’t need to do anything other than recognise it as valid syntax. Their main concern is that it "could add confusion with very little benefit."

The spec for STC has a critique of PTC:

- performance

- developer tools

- Error.stack

- cross-realm tail calls

- developer intent

See: https://github.com/tc39/proposal-ptc-syntax#issues-with-ptc

Apple's 2016 response as to why they won't implement STC is here: https://github.com/tc39/ecma262/issues/535

- STC is part of the spec and will take too long to change.

- Now that they've implemented support for PTC, they don't want to regress web pages that rely on it.

- They don't want to discourage vendors from implementing PTC by agreeing to STC.

- They don't want to introduce confusion.

Some of these arguments about confusion and delays seem wrong hindsight, since on every point things would have been better if they'd just agreed to the compromise of STC.

- It would have been part of the spec years ago

- STC would have had a clear way for web pages to know when tail calls could be relied on (and PTC would have been optional)

- Other vendors didn't implement PTC in any case, despite no agreement on STC

- There's even more confusion as things are now

You can see a direct example of this with Proper Tail Calls (PTC). It was added to the ECMAScript spec in 2015 as part of es6, but as of today - 7 years later - only Safari has shipped it*. As a result it is effectively not a thing in JavaScript, and the followup proposal meant to address issues with PTC ("Syntactic Tail Calls") has been basically ignored because PTC is already in the spec.

V8 implemented tail call optimization in the past, and the V8 team backed the TC39 proposal for syntactic tail calls (where you'd write return continue func() to make the use of TCO explicit). In Node 6 and 7 we could use them with the flag --harmony-tailcalls. The feature was removed from Node 8 after that proposal didn't go anywhere, but it's interesting, and shows some interest.

You can parse many things from this file, what are you trying to extract?

https://github.com/WebAssembly/spec/blob/main/document/core/...

Still strikes me as super sad JS never got SIMD support. It seemed like there were some strong candidate specs. On Node there are some add-on npm libraries that implement.

My understanding was the main protest was that we would get wasm & some certain implementers said they wanted to focus their energy on wasm.

That was well over half a decade ago & wasm is still in incredible infancy, with basically only statically linked capabilities in the spec.

Wasm SIMD proposal itself only merged into wasm in November 2021. https://github.com/WebAssembly/spec/pull/1391

It seems really unfortunate to have decided to keep JS the slow inferior language.

Blazor and WASM itself (outside of dotnet) are relatively new tools and they already show impressive results. They will keep getting better with every release. E.g. this proposal https://github.com/WebAssembly/spec/blob/main/proposals/simd/SIMD.md which should bring WASM closer to "near native speed". Blazor already started working on it true.

Big fan of this author's work.

They have a Gameboy emulator written in C, which can be compiled to WASM and run in the browser.

https://github.com/binji/binjgb

I learned a lot from the code.

Also I love this project with a bunch of demos in hand-written WebAssembly Text (WAT) format, which is like low-level Lisp that works only with raw memory, numbers, and minimal syntax.

https://github.com/binji/raw-wasm

Then I discovered the same author is quite active in the WebAssembly ecosystem, including specs and tooling. Fascinating stuff!

https://github.com/WebAssembly/spec

https://github.com/WebAssembly/wabt

[The WebAssembly specification (https://webassembly.github.io/spec/) maintains that the standards apply to more than just the browser host, but also to any other compliant host runtime (what the specification refers to as an embedder).

Heya,

(1) Thank you for implementing this in JSC!! I hope they take it, it makes it into Safari, and the tail-call proposal advances.

(2) I don't think you are exactly right about the call stack being observable via thrown exceptions. There's no formal spec for the v3 exceptions proposal yet, but in the documents and tests, there's nothing that would change in WebAssembly core to make the call stack observable. It's true that the proposal amends the JS API (but only the JS API) to describe a traceStack=true option; from Wasm's perspective I understand that's just an ordinary exception that happens to include an externref value (just like any other value) to which Wasm itself attaches no special significance. The engine can attach a stack trace if it wants, but there's no requirement (here) about what that stack trace contains or whether some frames might have been optimized out.

(3) I think the real reason that a Wasm engine can't implicitly make tail calls proper is that the spec tests forbid it, basically because they didn't want the implementation base to split by having some engines perform an optimization that changes the space complexity of a program, which some programs would have started to depend on (the spec tests say: "Implementations are required to have every call consume some abstract resource towards exhausting some abstract finite limit, such that infinitely recursive test cases reliably trap in finite time. This is because otherwise applications could come to depend on it on those implementations and be incompatible with implementations that don't do it (or don't do it under the same circumstances.)" More discussion here: https://github.com/WebAssembly/spec/issues/150

The WASM paper discusses that in the final section: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf

WebAssembly has a formal specification that includes both operational semantics and natural language-based descriptions of everything in the language. The official repository also has a lot of tests. Besides tests, you should be able to find lots of examples by searching.