AST in JSON format
Maciej Stachowiak
mjs at apple.com
Mon Dec 7 08:56:08 PST 2009
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
>>
>>
More information about the es-discuss
mailing list