Spawn proposal strawman

[Brendan Eich]

On May 21, 2009, at 4:15 PM, Kris Kowal wrote:

> 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.

Premature optimization?

Implementations can do ccache(1)-style compiled-results-caching.


> 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.

SpiderMonkey used to have a Script object you could create via s = new  
Script(source), or s = Script.compile(source) -- then you'd s.exec()  
to run the script. It was eval split in two. That made it pure evil,  
since the implementation couldn't analyze for it easily to deoptimize  
the calling code so that its scope could be used. We had code to  
deoptimize at runtime, but that was many years ago, when we didn't  
optimize much.

I don't think we want any such primitives split from eval's guts,  
although if we were to have these, the eval-as-container idea Mark  
started and you ran with does have appeal, since eval is already a  
quasi-keyword that implementations must recognize: eval. 
{parse,compile,exec}.

Anyway, AST serialization is what I'm working on (back burner this  
week). Beyond that is a cliff....

/be