AST in JSON format
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...
Size: 292 bytes
Desc: OpenPGP digital signature
More information about the es-discuss