Hermetic Evaluation, Modules Strawman

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

-Charles

On Sep 30, 2009, at 4:33 AM, Kris Kowal wrote:

> 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] http://wiki.ecmascript.org/doku.php?id=strawman:modules
> [2] http://wiki.commonjs.org/wiki/CommonJS
> [3] http://narwhaljs.org/
> [4] http://wiki.commonjs.org/wiki/Modules/SecurableModules
> [5] http://wiki.commonjs.org/wiki/Modules/Meta
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list