AST in JSON format

Oliver Hunt oliver at
Tue Dec 8 11:28:55 PST 2009

On Dec 8, 2009, at 2:18 AM, David-Sarah Hopwood wrote:

> Oliver Hunt wrote:
>> <snip>
>>> OTOH, if we standardize an AST format, then presumably we'll be adding
>>> a source->AST API function that uses the implementation's existing parser.
>> I'd be worried about assuming that this is an obvious/trivial thing for
>> implementations to do, you're effectively requiring that the internal AST
>> representation of an implementation be entirely standardised.
> Not at all. An implementation could, for example, parse to its internal
> AST format and then convert from that to the standard format (which is a
> trivial tree walk). This only requires that the internal format not lose
> information relative to the standard one. If it does currently lose
> information, then changing it not to is relatively straightforward.

And here you are assuming that ES implementations don't lose information, which is an incorrect assumption.  I believe spider monkey at minimum does constant folding while parsing, JSC does constant folding, variable and function hoisting, it also does not actually generate an AST at all for function bodies.

> In any case, without a source->AST API, what use is a standard AST format?
> The existance of that API (and the corresponding AST->source pretty-printing
> API) is the main motivation for standardizing the format, AFAICS.

That's kind of my point -- adding an ES API to get the parse tree requires one of two things, it's either specifying the internal implementation of an engine's parser, or it's requiring a second parser.  Both of these alternatives seem bad.

I have also yet to see an actual developer centric use case -- the most frequently repeated use cases seem to be analysis tools used to ensure code can be run on a standard ES implementation while essentially being a stricter subset of ES.  The developer scenario for that is "developer wishes to use 'safe' subset of ES", not "developer wants to perform their own analysis"


More information about the es-discuss mailing list