Hermetic Evaluation, Modules Strawman

[Kris Kowal-2]

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@...
https://mail.mozilla.org/listinfo/es-discuss

[Charles Jolley]

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@...
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss

[Kris Kowal-2]

Sorry, used to google groups, where reply is implicitly reply-all.
Here's my response to Charles:

---------- Forwarded message ----------
From: Kris Kowal <kris.kowal@...>
Date: Wed, Sep 30, 2009 at 12:45 PM
Subject: Re: Hermetic Evaluation, Modules Strawman
To: Charles Jolley <charles@...>


On Wed, Sep 30, 2009 at 10:20 AM, Charles Jolley <charles@...> 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
_______________________________________________
es-discuss mailing list
es-discuss@...
https://mail.mozilla.org/listinfo/es-discuss