Ihab - thanks for that info. My basic first cut of evaluating JsonML was implemented in C++ by treewalking the ES objects and building the AST. (Not sure why i went down the string parsing road). I could put the code into ecmascript-ast which people could experiment with on V8 (and then JSC).
ES-Harmony - or it's prototype - could be pure ES - if the translation from the AST in ES Objects to the native AST is fast enough. Maybe ES6 could focus on the core semantics that dev's want: lexical vars, 'hermetic eval' etc. (And maybe syntax cleanup - eg mandatory ; and ideas from JSLint). Then the sugar is build on the 'good bits' 'kernel' ES language/semantics. On Wed, Dec 23, 2009 at 6:48 PM, <[email protected]> wrote: > On Wed, Dec 23, 2009 at 10:45 AM, Kevin Curtis > <[email protected]> wrote: >> The strawman has been updated with an 'ast' entry: >> http://wiki.ecmascript.org/doku.php?id=strawman:ast > > I did that. I needed something to point to when I said, in a separate > (as of yet unpublished) proposal, that "${that} would be a nice thing > to have". > >> 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. > > Yes, that's what I was thinking. > >> 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. > > Yep. > > Ihab > > -- > Ihab A.B. Awad, Palo Alto, CA > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
