I initially thought that: parse(program:String):AST would return a handle to the native c/c++ AST tree.Then the question was if this native AST tree should be manipulatable by javascript ie should there be a wrapper javascript api which updates the native tree. Python says no - its native asdl c AST tree is not manipulatable by Python. Rather a copy is made into pure Python objects which can be manipulated and then converted back to a new native adl ast. So the native AST is immutable.
I was thinking along the lines of: var astObj = parse(js_source) // returns a handle to a immutable native c/c++ AST object var jsonML = astObj.toJson() // the ast object has a single method - toJson() which returns a jsonML string //the jsonML is manipulated either as as a string or via JSON.parse var jsonAstObj = JSON.parse(jsonML) .... processing var jsonML2 = JSON.stringify(jsonASTObj) var ast2 = parseJson(jsonML2) // create a handle to new immutable native ast object execute(ast2) This would cover the 2 use cases of: - efficient processing re processing the AST when no javascript manipulation of the AST is required, as in fast sandboxing. ie no use of ast.toJson and parseJson methods. - manipulating the AST in javascript for templating etc via jsonML There could be issues re resource usage/garbage collection of native AST object. Maybe the ast object could have a method - release(). On Fri, May 22, 2009 at 12:15 AM, Kris Kowal <[email protected]> wrote: >>> kevin curtis wrote: >>>> Is a 'canonical' AST part of the plans for ecmascript 6/harmony. > >> On May 9, 2009, at 9:19 AM, David-Sarah Hopwood wrote: >>> I hope so; that would be extremely useful. I would like to see an >>> ECMAScript source -> AST parser (as well as an AST evaluator) in the >>> Harmony standard library. > > On Sat, May 9, 2009 at 11:57 AM, Brendan Eich <[email protected]> wrote: >> We've wanted this since early in ES4 days. It would help many projects and >> experimental extensions (type checkers, template systems, macro processors, >> etc.) to have a standard AST, which could be serialized to JSON. > > Other neat uses for the AST would potentially include comment scraping > for automated documentation tools and minification, which have their > own requirements beyond those for execution, optimization, and static > analysis. > > Upon further reflection, I'm not sure that parse(program:String):AST > would serve the purpose of fast sandboxing. The intent of splitting > parse and execute is to reduce the cost of execution, so that modules > can be reused in many small sandboxes. Having parse produce a > (mutable) AST, and then leaving execute to translate the AST for the > interpreter might constrain our options for producing the desired > performance. It might be better to have a compile() routine that > returns an opaque, engine-specific Program object that can in turn be > executed multiple times. > > Kris Kowal > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
