AST in JSON format

Kevin Curtis kevinc1846 at googlemail.com
Mon Dec 7 10:02:15 PST 2009


On Mon, Dec 7, 2009 at 4:56 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> I could see a potential use case for a format that was more compact and/or
> faster to parse down to an executable form than JS source. However, for size
> the fair comparison should probably be to JS source that has been run
> through a source-to-source minimizer/compressor, and with both run through
> gzip. I seriously doubt any text-based AST format will do better under these
> conditions.

V8 has the implementation idea of symbols - frequently used strings -
such as 'valueOf, String, Number' etc. In ES5 'Object.defineProperty'
etc is going to be used quite frequently. It would be possible to to
turn these common Call strings into integers in JsonML. If the Call Id
is an integer than it is considered a direct call to one of ES5's
non-monkeypatched 'special forms'. Given the amount of object
hardening factories that i imagine will be written this could be a
win.
["Call", ["Property", ["Id", {name:"Object"}, ["Id", "defineProperty"]]
[33,[55,{4:12}...

Maybe that would be more compact. Though it's stretching!

> If we really want to minimize size for delivery and parsing speed, then
> probably some sort binary format with built-in compression would be most
> useful, though there would be risk presented in properly validating such a
> format.

Maybe the ByteVector proposal offers possibilities in this area! (With
a module system could this be namespaced within a native builtin
module? Then Data could be a name possibility. Though having
ByteVector as top-level and immediately accessible is sweet).

Overall, there seems to be a tension between those who wish to treat
the ECMAScript as a semantic runtime with serverside compilers
generating compact, optimized JS and those who want to add sugar to
the language so that the it could compete with - say Python - for user
friendliness as a general purpose PL. I prefer to reduce the language
and then add any necessary core semantics for safety, speed and
simplicity. Then let DSL's compete for the best sugar - C syntax or
otherwise.

> Actually, this is potentially a factor for any natively supported AST
> format. If execution is direct rather than via transoformation to JS source,
> the implementation would have to verify that the AST is one that could be
> created by parsing JS source.

Though in some ways a JsonML format - or whatever - offers freedom
from JS backward compatibility issues. Want a new keyword:
["Import", ...

Regards.


More information about the es-discuss mailing list