AST in JSON format

Brendan Eich brendan at mozilla.com
Mon Dec 7 18:41:44 PST 2009


On Dec 7, 2009, at 4:28 PM, Kevin Curtis wrote:

>> (This is as considered separately from the possibility of  
>> programatically
>> manipulating a parsed AST - the use cases for that are clear.  
>> Though there
>> may still be verification issues depending on the nature of the  
>> manipulation
>> API. It seems like the possibilities are either specialized objects  
>> that
>> enforce validity on every individual manipulation, or something  
>> that accepts
>> JSON-like objects and verifies validity after the fact, or  
>> something that
>> accepts JSON-like objects and verifies validity by converting to  
>> JavaScript
>> source code and then parsing it).
>>
>> Regards,
>> Maciej
>>
>
> I asked something similar here:
> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009243.html
>
> Are there 2 approaches to adding AST functionality in ecmascript:
>
> 1) The AST as JSON
> Either Brendan's original example or the S-expression-ish jsonml.
> This covers both the in memory representation of the AST and its
> serialization format.

I withdrew my sketch in favor of the JsonML direction back in the  
original thread.


> 2) API
> Similar to the ast module in python where multiple api calls build the
> AST nodes.
>
> ----
> Given that there are no takers for 'scheme by the back door', then,
> with the object hardening features of ES5 - 2) should be considered.
> e.g:
> //  assume an ast module factory
> var x = ast.BinOp("+", 4, 5);
> x.left = 6;
> x.right = 7
> x.whatever = 8 // error
>
> The Python ast module has a dump method which dumps the AST tree of
> Python objects to a string of nested functions calls - which can be
> eval'ed to recreate in memory.

As I think David-Sarah just pointed out, using too much memory to  
express something that can be encoded in a much smaller string can be  
a bit of a lose.

Standardized ASTs are not a done deal, they constitute a prior work  
item, call it 0. We should check whether it is something TC39 members  
could agree on in more detail before going too far, although some  
popular implementations and a bit of luck not over-constraining parser  
implementation choices could lead to adoption and de-facto  
standardization.

/be


More information about the es-discuss mailing list