I could see a potential use case for a format that was more compact
and/or faster to parse down to an executable form than JS source.
However, for size the fair comparison should probably be to JS source
that has been run through a source-to-source minimizer/compressor, and
with both run through gzip. I seriously doubt any text-based AST
format will do better under these conditions.
I also note that your compact form no longer seems very useful for
direct manipulation of the AST, so presumably the use case would be
different.
If we really want to minimize size for delivery and parsing speed,
then probably some sort binary format with built-in compression would
be most useful, though there would be risk presented in properly
validating such a format.
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.
Regards,
Maciej
On Dec 7, 2009, at 8:13 AM, Kevin Curtis wrote:
True. JS as the ultimate delivery mechanism is most likely. With JSON
serialization comes for free i guess.
Though i propose an 'compact format' - which is definitely
'speculative':
Perhaps there could an alternative compact format where the element
strings are replaced with integers:
[44,[20,[21,{"op":"="},[25,{"name":"x"}], ...
And the attribute name string with an integer or maybe the first
letter:
[44,[20,[21,{1:"="},[25,{3:"x"}], ...
[44,[20,[21,{"o":"="},[25,{n:"x"}], ...
It's compact and as the integers match the underlying enum no hash
lookup for the element/attribute string names is required. Kind of a
half way house between the AST and bytecode.
var ast = JSON.AST.parse(source, true); // true for compact mode
var result = JSON.AST.evaluate(ast); // No special mode required
The evaluate function would simply test if the element value was a
string or integer and hash lookup or atoi.
On Mon, Dec 7, 2009 at 3:45 PM, Maciej Stachowiak <[email protected]>
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?
Regards,
Maciej
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
