AST in JSON format

Kevin Curtis kevinc1846 at
Mon Dec 7 08:13:52 PST 2009

True. JS as the ultimate delivery mechanism is most likely. With JSON
serialization comes for free i guess.

Though i propose an 'compact format' - which is definitely 'speculative':

Perhaps there could an alternative compact format where the element
strings are replaced with integers:

[44,[20,[21,{"op":"="},[25,{"name":"x"}], ...

And the attribute name string with an integer or maybe the first letter:
[44,[20,[21,{1:"="},[25,{3:"x"}], ...
[44,[20,[21,{"o":"="},[25,{n:"x"}], ...

It's compact and as the integers match the underlying enum no hash
lookup for the element/attribute string names is required. Kind of a
half way house between the AST and bytecode.

var ast = JSON.AST.parse(source, true); // true for compact mode
var result = JSON.AST.evaluate(ast); // No special mode required
The evaluate function would simply test if the element value was a
string or integer and hash lookup or atoi.

On Mon, Dec 7, 2009 at 3:45 PM, Maciej Stachowiak <mjs at> wrote:
> On Dec 7, 2009, at 7:22 AM, Kevin Curtis wrote:
>> This covers the origin of the idea and some of it's uses:
>> I'm interested in JsonML AST as a DSL target.
>> Hacking the YACC file in jsc to parse the ES5 grammar as expressed in
>> JsonML could yield an (executable) spec of sorts.
> I can see how modifying the AST client-side prior to execution could be
> useful, to implement macro-like processing. But I don't see the use case for
> serializing an AST in JSON-like format, or sending it over the wire that
> way. It seems like it would be larger (and therefore slower to transmit),
> and likely no faster to parse, as compared to JavaScript source code. So
> shouldn't the serialization format just be JS source code?
> Regards,
> Maciej

More information about the es-discuss mailing list