simple modules

[Brendan Eich]

On Feb 3, 2010, at 11:10 AM, Kevin Curtis wrote:

> Is there a fundamental theoretical comp sci reason why module state  
> is shared?

Sam knows more about such things than I do, but my answer is "who  
cares?" :-P Computer scientists and programming-language theorists do  
not all agree on whether to countenance mutation, and if so, how to  
handle it. But it is part of JS, and it's not going away. The simple  
modules proposal starts with goals including:
   Be compatible with:

Security mechanisms and idioms
State isolation mechanisms
But being compatible with these things does not mean making them the  
only or default way.


> Is the core idea of using lexical scoping in the simple_module  
> proposal undermined by not having shared state.

Probably, since the rest of the language does not combine lexical  
scope and no-sharing by default.

More important: the core idea of "simple" modules is undermined.  
Lexical scope is great and all, but separate. You can use lexical  
scope and functions today to create singleton and multiple-instance  
state sharing patterns.

Switching to lexical scope in modules is important if you are trying  
to avoid stepping on your own, or your friends', toes -- especially  
for early error checking.

Switching to unshared state by default is neither necessary nor  
helpful to the simple_modules goal

  Total compatibility with non-module code

Many languages with second-class module systems and lexical scope do  
not make unshared the default. And you can control state sharing with  
orthogonal tools (more below), so this is not a deal-breaker.


> If not, could possibly non-shared state be the default behaviour.  
> And shared state modules - which share state within contexts - are  
> somehow marked as shared at module definition. e.g.
> module ModShared {
> "use shared" // or some mechanism to signify shared state

We've reached tentative agreement on how to subset the language so  
that stateless, zero-authority modules can be the only modules  
available to the secure subset, with anything powerful carefully  
introduced ("whitelisted", see my reply to Kris just now; of course  
whitelisting really is an overstatement, or over-broad statement in  
ocap/POLA terms; and no one proposes blacklisting in the subset  
language).

Let's not go back on this tentative agreement by trying to push the  
full language away from sharing of mutable lexically bound state. It's  
not going to fly in the simple modules proposal, because it removes  
simplicity.

Even if the only change were to require a module to self-declare itsel  
as "shared", to have teeth, that would mean the default (unshared)  
module cannot be imported N times, N > 1, and have mutable singleton  
state that it counts on. And that requires changes to the importing  
code, to keep track of or memoize the singleton. It does not merely  
change the way the shared-state module is defined. This approach  
really wants Ihab's emaker-style modules.

With simple modules as proposed, if you want emaker-style modules (a  
fine pattern), then use a function! JS already has first-class  
functions, and with ES5 Object.freeze, etc., there is no overriding  
need in the full Harmony language to wrap up the notion of module with  
constructor function so tightly just to make non-shared mutable state  
the default. Simplicity is best served by keeping primitives  
orthogonal and composable.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100203/8956217e/attachment.html>