Spawn proposal strawman

[kevin curtis]

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 <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
> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>