AST in JSON format

Mark Miller erights at gmail.com
Mon Dec 7 14:29:39 PST 2009


On Mon, Dec 7, 2009 at 7:45 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Dec 7, 2009, at 7:22 AM, Kevin Curtis wrote:
>
>> This covers the origin of the idea and some of it's uses:
>> https://mail.mozilla.org/pipermail/es-discuss/2009-May/009234.html
>>
>> I'm interested in JsonML AST as a DSL target.
>>
>> Hacking the YACC file in jsc to parse the ES5 grammar as expressed in
>> JsonML could yield an (executable) spec of sorts.
>
> 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.


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM


More information about the es-discuss mailing list