3 ms·
> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. I'm afraid your statement really wasn't
by dherman 13y ago
> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode.
I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.
- justinschuh 13y agoI'm sorry if I'm coming across negatively. It's not my intent. And please don't presume that my concerns about asm.js are in any way tied to projects that other people in Google/Chrome work on, or that I'm entirely supportive of them. That said, I am curious if you really are committing to to future versions of asm.js not using any divergent APIs or observable divergent behavior from JavaScript as used on the web?
- dherman 13y agoDiverging from JS would require standardization, but it's too early to consider something like that. I don't know what our ultimate plan for threads will be or where asm.js will eventually end up; there are plenty more discussions to be had.
- justinschuh 13y agoThanks, that's a bit of helpful context. I appreciate that it's too early to say where exactly asm.js will go. I'm just afraid of private APIs or other divergence from JavaScript in order to mainstream asm.js. Sorry if that apprehension came across as overly negative.