kevinc1846 at googlemail.com
Wed Dec 23 10:45:09 PST 2009
The JsonML AST was a half-baked go at 'scheme by the backdoor'.
(Though I muddied the water with the idea of using JsonML as a
transport protocol. Doh.).
The strawman has been updated with an 'ast' entry:
Re: "In order for this to be practical, most of the current ECMAScript
utilities that currently take program text as a string would need to
be extended to accept an AST as well."
Is this something like the Python ast module:
ast.parse() would parse ECMAScript source to an AST of ECMAScript
objects. Could be pure ES.
eval() would take an AST tree of ECMAScript objects. The
implementation would walk the tree of ES objects to build the native
C++ AST (which is then used to generate and execute code). This is how
the Python ast module works.
Could this revised eval(|AST of ES Objects|) be an be a
efficient/realistic target for alt-JS's/DSL's/rewriters/LINQ? It
should be straightforward to implement. The native C++ AST remains an
unconstrained 'artefact of the implementation' given that ast.parse()
is pure ES.
More information about the es-discuss