Brendan Eich brendan at
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 
explicit goal.

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 <mailto:till at>> wrote:
>     On Mon, May 19, 2014 at 3:55 PM, Florian Bösch <pyalot at
>     <mailto:pyalot at>> 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

More information about the es-discuss mailing list