JS is getting int64 and uint64, so you need a better example, like zero-cost exceptions, dynamic linking, call/cc (listed in my post).

Can you link to where that is being discussed? I hadn't heard that int64 was being added. My google-fu has failed to turn up anything. int64 would be very useful for long types in ScalaJs. They run really slow because they have to be emulated with the whole split it into smaller parts stuff. Lots of jvm targetting code I have ported at work was written with the "just use a long, it's not much slower than an int" thought process, true on the JVM, not true in JS.

> JS is getting int64 and uint64

It's a fine example for today's browsers that don't have those. Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs. And it doesn't invalidate the point that JavaScript limitations should not be web limitations.

For instance, how about efficient structs with defined in-memory layout?

Targeting web APIs to WebAssembly means that the web can tell JavaScript to keep up, rather than JavaScript telling the web to wait up.

Wait, how does wasm help APIs being designed today?

Please use the same yardstick when comparing.

Important that JS grow too, including SIMD, shared memory, value types including 64-bit int. Does not alter the case for wasm, per the FAQ: parse time win soon, divergence to relieve JS from serving two masters in longer run.

I'm using the same yardstick, relative to the baseline implementation of each language. APIs won't be able to natively target WebAssembly until browsers have native support for it. However, once browsers natively support WebAssembly, there won't need to be a "today's WebAssembly" versus "tomorrow's WebAssembly" issue; interesting new features belong in the languages targeting WebAssembly, with WebAssembly itself handling things like "how do we efficiently generate SIMD instructions on every target platform". Questions like "what datatypes do we support" become uninteresting; the answer is "whatever both ends of an ABI can agree on".

You wrote

"Fixing that for future JavaScript doesn't help APIs being designed today, or existing APIs."

and I asked

"Wait, how does wasm help APIs being designed today?"

Your different yardstick is the shift from "today" to "future". WebAsm that is a super of JS is in the future, past the polyfill era of co-expressiveness. Fault JS today for lacking int64 by the same (temporal) yardstick should fault wasm today.

In general we agree, but you are arguing carelessly. There is no essential difference between int64 for JS in the future, and int64-equipped wasm in the future. Both are in the future.

The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS. But it'll be a managed standards, so don't expect a huge iteration-time win. It'll be good for both JS and wasm in that farther future to decouple concerns, I agree.

Are we done yet?

I'm talking about the meta-problem here: APIs designed today have to care about today's JavaScript semantics, which are high-level JavaScript-specific constraints. APIs designed for browsers with native wasm support care about the semantics of wasm, but those semantics are language-agnostic. APIs should be designed based on a language-agnostic ABI, not based on JavaScript. That's the world I'm looking forward to.

Even the planned future ABI for interoperable dynamic linking is a guideline; any caller and callee that agree can use a different, extended ABI.

> The solid ground on which to argue is where browsers all update to support wasm, whose syntax and extension model(s) stabilize, and then wasm can run ahead of JS.

Of course, and that's exactly the world I'm talking about.

> But it'll be a managed standards, so don't expect a huge iteration-time win.

WebAssembly is in a very critical way smaller than JavaScript, so its iteration time is less important. wasm iterations will be important for performance (to provide constructs that will efficiently translate to the native machine code you or a compiler would have written), and we'll need new APIs for things like thread-spawning, but new language features and functions using those features won't require any changes to wasm.

> Are we done yet?

By all means let's stop violently agreeing with each other. :) Thanks for working on WebAssembly; I look forward to using it.

> APIs should be designed based on a language-agnostic ABI, not based on JavaScript.

Has there ever been such a thing?

http://x86-64.org/documentation/abi.pdf , for one example.

Regardless of the timing and the specific example of int64/uint64, isn't the benefit being discussed by JoshTriplett the same thing you are talking about with divergence? If the low-level language of the web is divorced from JS so that each can evolve independently, future web APIs that are designed to be consumed from multiple (high-level) languages can be specified in terms of structures that can be represented in the low-level language, and high-level language-specific bindings to the low-level APIs can present an interface customized to the type systems and idioms of the specific high-level language with the appropriate low-level shims to convert to the low-level representation.

Any possibility for consideration of composable continuations as a WebAssembly language feature, e.g. shift/reset in Racket?

See: Adding Delimited and Composable Control to a Production Programming Environment

https://www.cs.utah.edu/plt/publications/icfp07-fyff.pdf