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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
