AST in JSON format
brendan at mozilla.com
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 (http://jsbeautifier.org/) 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
Compression at the transport (session, whatever, the model is climbing
the traditional layering) is a separate issue.
More information about the es-discuss