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?
/be
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
<t...@tillschneidereit.net <mailto:t...@tillschneidereit.net>> wrote:
On Mon, May 19, 2014 at 3:55 PM, Florian Bösch <pya...@gmail.com
<mailto:pya...@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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
