AST in JSON format

David-Sarah Hopwood david-sarah at jacaranda.org
Mon Dec 7 15:54:12 PST 2009


ihab.awad at gmail.com wrote:
> On Mon, Dec 7, 2009 at 3:10 PM, David-Sarah Hopwood
> <david-sarah at jacaranda.org> wrote:
>> ... programmers of AST-processing applications will see this
>> serialization when debugging, and it is likely to appear in test
>> cases for such applications and for parsers/emitters.
> 
> Also: would a JsonML representation be *quicker* to execute than the
> original human readable JS source? If so, it could be useful as a wire
> format for the code of mobile objects.

Parsing ECMAScript correctly is hairy, complicated, and likely to be
inefficient unless you have a lot of time to spare to optimize the parser
(as I'm sure you know from Caja :-). Parsing a JsonML serialized AST is
trivial: use JSON.parse.

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.
If and when such an API is available, there would be little reason to use
the JsonML serialization as a wire format.

> Furthermore, this format could be a good target for *generated* code.

The in-memory AST, yes. Also possibly the serialized form where the
code generator is written in a language other than ECMAScript (since
writing a correct JSON emitter, even if you can't reuse one, is *much*
easier than writing a correct ECMAScript emitter).

> On the other hand, this discussion slowly creeps into asking whether
> (say) collaborative IDEs and could benefit from such a common
> representation. For that use case, it would be necessary to support
> comments, which would grow the problem space considerably....

It depends whether you just want to preserve comments, which is pretty
easy and would be quite a useful *option* (especially for "doc-comments"),
or whether you want to preserve whitespace, which I think should be
considered out-of-scope for an AST format.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20091207/7ce1ae16/attachment.bin>


More information about the es-discuss mailing list