brendan at mozilla.org
Mon May 19 10:20:24 PDT 2014
I take a more expansive view, because of evolution. JS and languages
that currently target it, and also languages that might in the future
target it, are co-evolving. They influence one another.
JS is growing SIMD and other lower-level APIs (perhaps even
ARB_compute_shader in a future WebGL iteration). Value objects for more
numeric types are coming.
Also, the Harmony era has JS as better target for compilers as an
So it seems to me worthwhile to talk about certain "multi-language VM"
design issues. Bytecode in general, perhaps a standard, fast,
zero-verification AST codec format, seems fair game for es-discuss.
But I agree that putting the bytecode syntax cart ahead of the horses
(language designs and their semantic requirements) is a mistake. As
McCarthy suggested, there may be several concrete syntaxes. What's the
abstract syntax, and ahead of that, what does it mean?
Florian Bösch wrote:
> Well, it is a thread on bytecode, that had a discussion on bytecode,
> but sure, whatever.
> On Mon, May 19, 2014 at 4:07 PM, Till Schneidereit
> <till at tillschneidereit.net <mailto:till at tillschneidereit.net>> wrote:
> On Mon, May 19, 2014 at 3:55 PM, Florian Bösch <pyalot at gmail.com
> <mailto:pyalot at gmail.com>> wrote:
> So just so I get this straight. You're talking about a
> bytecode format, which implies some kind of revamped
> features/VM to run it, but you won't be discussing anything
> other than ECMAScript as the targeting semantic. Sorry to say,
> but then that's a pretty useless discussion entirely.
> No, I don't want to talk about a bytecode format *at all*. At
> least not on this list, as this list is about ECMAScript, and
> nothing else. If you want to make the case for a bytecode format
> for the web, take it to some other forum.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss