Hermetic Evaluation, Modules Strawman
charles at sproutit.com
Wed Sep 30 10:20:17 PDT 2009
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.
On Sep 30, 2009, at 4:33 AM, Kris Kowal wrote:
> I've begun my work on a second draft  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  and Narwhal  implementations of the
> SecurableModules  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 , 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
>  http://wiki.ecmascript.org/doku.php?id=strawman:modules
>  http://wiki.commonjs.org/wiki/CommonJS
>  http://narwhaljs.org/
>  http://wiki.commonjs.org/wiki/Modules/SecurableModules
>  http://wiki.commonjs.org/wiki/Modules/Meta
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss