Mark Miller wrote: > On Mon, Dec 7, 2009 at 7:45 AM, Maciej Stachowiak <m...@apple.com> wrote: > >> I can see how modifying the AST client-side prior to execution could be >> useful, to implement macro-like processing. But I don't see the use case for >> serializing an AST in JSON-like format, or sending it over the wire that >> way. It seems like it would be larger (and therefore slower to transmit), >> and likely no faster to parse, as compared to JavaScript source code. So >> shouldn't the serialization format just be JS source code? > > +1. > > While potentially useful, I have no interest in these ASTs as a > serialization format nor in a compact AST encoding. I am interested in > having a standard JsonML AST encoding of parsed ES5, and eventually an > efficient and standard browser-side parser that emits these ASTs. Many > forms of JS meta-programming that currently occur only on the server > (e.g., Caja, FBJS, MSWebSandbox, Jacaranda) or have to download a full > JS parser to the client per frame (ADsafe, JSLint, Narcissus, > Narrative JS) could instead become lighter weight client side > programs.
+1. Note that: - although the size of the JSON serialization of the AST is not critical for this kind of usage, the size of the in-memory representation definitely is. - encoding node type strings as integers, as suggested earlier in the thread, does not help with this memory usage. - any Lempel-Ziv-based compression algorithm will do much better than replacing type strings with integers, in the few situations where it is useful to serialize the AST and to minimize the size of the serialization. - JsonML is a reasonable basis for an AST format even when "serialization for free" is of fairly low importance. In particular, it is useful that it only uses structures that are common across programming languages (for instance, the prototype Jacaranda verifier uses it even though it is written in Java). Also, 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. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
