>
> Hi Kevin, if nothing in the ES6 module system precludes lexical modules,
> why is postponing lexical modules and conceptual integrity till ES7 not an
> option? In the same sense, we likewise postponed most of what is needed for
> classes to have conceptual integrity (as well as literal integrity ;)) till
> ES7. And the lexical scope cleanups in ES5/strict, in the same sense,
> didn't have conceptual integrity until the const/let/modules of ES6. We
> can't get agreement on everything at once. Sometimes, we need experience
> with the things we do get agreement on to inform the discussions about the
> remainder.
>

With ES5/strict, you had severe constraints on new syntax.  With classes,
we still don't have a solid, agreed-upon way to represent private instance
state.  These are real constraints which have a real impact on what can be
done in the relevant timeframe.  Is there a similar constraint with lexical
modules?

Furthermore, it may be that by postponing lexical modules we end up
introducing features which we don't actually need:

Take this form, whose purpose is to allow for concatenation of modules into
a single file:

    // The "GlobalReg" form
    module "module-name" { }

If we have lexical modules, is this form truly necessary?  I think not.
 Given nested modules, we can create a tool which, for some "root" module
R, bundles R with all of R's dependencies in a way that *completely
encapsulates* those dependencies.  This encapsulation is not even possible
with the GlobalReg form.  The follow gist shows such a transformation:

https://gist.github.com/zenparsing/5355927

What's more, the GlobalReg form is very likely going to lead developers
toward a practice of *actually coding* in that form.  This will undoubtably
lead to yet another variation of global namespace pollution, as libraries
opportunistically register themselves under some single-word module name:

    // Another form of global namespace pollution:
    module "jquery" { ... }

There is a very real possibility that by postponing our work on lexical
modules we will have inadvertently created a problematic namespacing legacy
which we cannot get rid of.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130415/84ec65c5/attachment-0001.html>

>
> Hi Kevin, if nothing in the ES6 module system precludes lexical modules,
> why is postponing lexical modules and conceptual integrity till ES7 not an
> option? In the same sense, we likewise postponed most of what is needed for
> classes to have conceptual integrity (as well as literal integrity ;)) till
> ES7. And the lexical scope cleanups in ES5/strict, in the same sense,
> didn't have conceptual integrity until the const/let/modules of ES6. We
> can't get agreement on everything at once. Sometimes, we need experience
> with the things we do get agreement on to inform the discussions about the
> remainder.
>

With ES5/strict, you had severe constraints on new syntax.  With classes,
we still don't have a solid, agreed-upon way to represent private instance
state.  These are real constraints which have a real impact on what can be
done in the relevant timeframe.  Is there a similar constraint with lexical
modules?

Furthermore, it may be that by postponing lexical modules we end up
introducing features which we don't actually need:

Take this form, whose purpose is to allow for concatenation of modules into
a single file:

```js
// The "GlobalReg" form
module "module-name" { }
```

If we have lexical modules, is this form truly necessary?  I think not.
 Given nested modules, we can create a tool which, for some "root" module
R, bundles R with all of R's dependencies in a way that *completely
encapsulates* those dependencies.  This encapsulation is not even possible
with the GlobalReg form.  The follow gist shows such a transformation:

https://gist.github.com/zenparsing/5355927

What's more, the GlobalReg form is very likely going to lead developers
toward a practice of *actually coding* in that form.  This will undoubtably
lead to yet another variation of global namespace pollution, as libraries
opportunistically register themselves under some single-word module name:

```js
// Another form of global namespace pollution:
module "jquery" { ... }
```

There is a very real possibility that by postponing our work on lexical
modules we will have inadvertently created a problematic namespacing legacy
which we cannot get rid of.