AST in JSON format

[Maciej Stachowiak]

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.

I also note that your compact form no longer seems very useful for  
direct manipulation of the AST, so presumably the use case would be  
different.

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.

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.

Regards,
Maciej

On Dec 7, 2009, at 8:13 AM, Kevin Curtis wrote:

> 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 apple.com>  
> 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:
>>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009234.html
>>>
>>> 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
>>
>>