AST in JSON format

Brendan Eich brendan at
Mon Dec 7 10:11:33 PST 2009

On Dec 7, 2009, at 8:56 AM, Maciej Stachowiak wrote:

> 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.

This reminds me of SafeTSA:

and more specifically of work by Christian Stork and Michael Franz, see:

The idea as I first heard it from Chris and Michael was to  
arithmetically code ASTs such that no ill-formed tree could be  
encoded. You could take a JPEG of the Mona Lisa, run it through the  
decoder, and if it succeeded, get a (almost-certainly) nonsensical yet  
syntactically well-formed AST. The encoding is fairly efficient, not  
as good as optimized Huffman coding but close.

This work was motivated by the sometimes bad (O(n^4)) complexity in  
the Java bytecode verifier (or at least in early versions of it).

My view is that there will never be a standardized bytecode (politics  
look insuperable to me), and more: that there should not be. Besides  
the conflicts among target VM technical details, and ignoring latent  
IPR issues, I believe view-source capability is essential. Even  
minification lets one pretty-print ( and  
learn or diagnose.

JS is still used in edit-shift-reload, crawl-walk-run development  
style and part of this culture involves sharing. Of course no one  
could mandate binary syntax to the exclusion of source, but a binary  
syntax that did not allow pretty-printing would shove us all down the  
slippery slope toward the opaque, closed-box world of Java applets,  
Flash SWFs (modulo Flash+Flex's server-fetched view-source  
capabilities), etc.

Compression at the transport (session, whatever, the model is climbing  
the traditional layering) is a separate issue.


More information about the es-discuss mailing list