simple modules

[Brendan Eich]

On Feb 1, 2010, at 9:21 AM, Sam Tobin-Hochstadt wrote:

> On Mon, Feb 1, 2010 at 1:04 AM, <ihab.awad at gmail.com> wrote:
>> But, in some module M that imports X, Y and Z, the top-level lexical
>> environment *must* include access to all the state encapsulated by X,
>> Y and Z.
>
> That's only the case if X, Y, and Z provide access to their internal
> state via the bindings they export.  For example:
>
> module MemoFun {
>  var table = {};
>  export function f(x) {
>    if table[x] { return table[x]; }
>    // imagine complex but pure computation here
>    var tmp = x + 7;
>    table[x] = tmp;
>    return tmp;
>   }
> }
>
> Here, the only access provided to the state is via the function `f'.
> Outside modules cannot disturb the invariants of the code at all.

This is a crucial point, probably worth repeating: each module has its  
own lexical binding environment at its top level, not a global object.  
In the Harmony era wiki, this idea goes back at least as far as

http://wiki.ecmascript.org/doku.php?id=strawman:lexical_scope

As in the "use lexical scope" proposal, the new syntax of |module id  
{...}| changes the rules within the braces: no more global object.


>> In any case, my point stands. The namespaces for "pure code being
>> brought in" and "powers granted to me by my container" are being
>> conflated. For the former, you need modules. For the latter, you need
>> some sort of "service registry" or whatever else.
>
> I think that in many cases, conflating these two concepts is
> appropriate.  For example, if I import jQuery to add some simple bit
> of functionality to my homepage, I almost certainly want to give it
> access to all of the things I have access to.  This is the common case
> that our strawman tries to make simple.  However, in other contexts a
> service registry may be more appropriate, and that can be built on top
> of modules, using either the dynamic loading features, or simple
> lexical scope with functions and objects.

Another point worth highlighting: simple and common (and safe in their  
own terms) chores should be easy to write; more complex use-cases  
should be possible, while obviously less simple to express. Doing it  
the other way 'round, requiring the more complex forms to do simple  
thigns, overcomplicates the language.

The pitfall of having to do everything today on extant browsers using  
first class functions and objects (and code generators) should not  
dictate complexity for all use-cases in the integrated module system.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100201/79b1735e/attachment.html>