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: http://wiki.ecmascript.org/doku.php?id=strawman:ast 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. Regards. _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
