Hermetic Evaluation, Modules Strawman
You can tell me why this module design relies on eval'ing a string?
It would be nice to be able to pass a Function object also.
I wonder if that might be better for performance also as an optimized
implementation could potentially avoid re-parsing the JS. [Note: I
haven't implemented this kind of code before so there might not be any
gains to be had here...]
I'm thinking of a case where you have a large-ish module where the
cost of eval'ing is non-trivial.
Sorry, used to google groups, where reply is implicitly reply-all. Here's my response to Charles:
---------- Forwarded message ---------- From: Kris Kowal <kris.kowal at cixar.com>
Date: Wed, Sep 30, 2009 at 12:45 PM Subject: Re: Hermetic Evaluation, Modules Strawman To: Charles Jolley <charles at sproutit.com>
On Wed, Sep 30, 2009 at 10:20 AM, Charles Jolley <charles at sproutit.com> wrote:
You can tell me why this module design relies on eval'ing a string? It would be nice to be able to pass a Function object also.
I wonder if that might be better for performance also as an optimized implementation could potentially avoid re-parsing the JS. [Note: I haven't implemented this kind of code before so there might not be any gains to be had here...]
I'm thinking of a case where you have a large-ish module where the cost of eval'ing is non-trivial.
Absolutely. The idea is that the proposed new eval.Module(names, text) case would be analogous to a Function(names..., text) constructor, which would give the implementation an opportunity to compile the program, sharing the AST or byte code between invocations of the Module.
However, the purpose is definitely to transform text into a reusable component. The same purpose could potentially be achieved by "reparenting" a function declaration, such that the closure's parent scope reference is the hermetic, deeply frozen, primordial scope, but that would break lexical analysis in odd ways. Free variables in the function would become reference errors at call time.
Kris Kowal
I've begun my work on a second draft [1] of the module proposal that Ihab and I put forth at the January meeting. Just to get started, I wanted to emphasize that "all we need is hermetic evaluation", and re-propose the interface for hermetic eval in light of experience with the CommonJS [2] and Narwhal [3] implementations of the SecurableModules [4] proposal Ihab and I made to that group a week later. We've made a lot of great progress in the last 9 months in vetting the module system idea.
This new draft proposes that the primitive hermetic evaluator be more like the Function constructor and permits early exceptions for non-primordial, non-injected free variables. The new proposal is safer since it emphasizes that the module text must be a program construct, makes explicit what names are being injected into the program's scope, and explicates that, unlike "with" blocks, specific names are injected into a function block scope instead of placing a stock Object in the scope chain.
It's my intention to copy and edit sections of the original proposal into the wiki, making minor revisions to match up with CommonJS SecurableModules, the Module meta-object amendment [5], explicate synchronous and asynchronous variations of importing modules, and to specify the API's of module loaders and module sandboxes. Ihab is spearheading an effort on CommonJS to formalize "packages" of modules, their layout, their metadata, how to verify their signatures, and how to import modules from packages, which I hope to integrate in a future draft. We remain in discord about whether to conflate the name spaces of injected capabilities and modules, but we had a good discussion recently that might help us arrive at a compromise.
This all being said, between Object.freeze and hermetic evaluation, we can do a lot in libraries without native language support so it's worth kicking off a discussion around that feature early.
Kris Kowal
[1] strawman:modules [2] wiki.commonjs.org/wiki/CommonJS [3] narwhaljs.org [4] wiki.commonjs.org/wiki/Modules/SecurableModules [5] wiki.commonjs.org/wiki/Modules/Meta