quasi-literal strawman

Kevin Curtis kevinc1846 at googlemail.com
Wed Dec 23 11:06:53 PST 2009

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

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,  <ihab.awad at gmail.com> wrote:
> On Wed, Dec 23, 2009 at 10:45 AM, Kevin Curtis
> <kevinc1846 at googlemail.com> 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

More information about the es-discuss mailing list