Spawn proposal strawman
kevinc1846 at googlemail.com
Mon May 25 05:03:20 PDT 2009
I initially thought that:
would return a handle to the native c/c++ AST tree.Then the question
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)
var jsonML2 = JSON.stringify(jsonASTObj)
var ast2 = parseJson(jsonML2) // create a handle to new immutable
native ast object
This would cover the 2 use cases of:
manipulation of the AST is required, as in fast sandboxing. ie no use
of ast.toJson and parseJson methods.
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 <kris.kowal at cixar.com> 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 <brendan at mozilla.com> 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
> 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
> es-discuss at mozilla.org
More information about the es-discuss