Lexical Modules Can't Wait

Mark S. Miller erights at google.com
Mon Apr 15 08:13:59 PDT 2013


On Mon, Apr 15, 2013 at 6:41 AM, Kevin Smith <zenparsing at gmail.com> wrote:

> I think we can all agree that, in principle, program structures which have
> scope and define a namespace should be lexically identified and should
> nest, unless there is some compelling reason otherwise.
>
> A module, for any sane definition of the term in the context of
> Javascript, has a scope and defines a namespace.  Therefore, unless we can
> provide some overwhelming argument to the contrary, established design
> principles tell us that modules should be lexically identified and should
> nest.
>
> It has been suggested that we can postpone adding lexical modules until
> ES7.  But to do so would be to postpone conceptual integrity, which is not
> an available option.
>

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.

That said, I mostly agree with you on modules. I agree with everything you
say here. I say "mostly" only because I believe that modules definitions
should be allowed in any lexically nested context. When appearing in a
multiply-instantiated lexical context, such as the body of a function, the
module definition should itself be multiply instantiable (or generative) as
well. This has been true for all defining forms in JavaScript, and it has
been a great virtue. However, I don't actually have a coherent end-to-end
proposal for making this work (<
http://wiki.ecmascript.org/doku.php?id=strawman:simple_module_functions>
doesn't work), and it is clear that I could not agreement on one at the
present time even if I had one.

Moving a consensus forward takes patience, and a sense of which starting
steps may productively lead to which paths. ES6 is mostly settled. We
should already be focussing most of our unrealized design ambitions on ES7.




>
> By postponing at-names, for example, we only postpone the usability of
> symbols-as-property-names.  But by postponing lexical modules, we postpone
> the clarity of our design.  Indeed, there is nothing in ES6 which requires
> more conceptual clarity than modules.  Modules should be the mountain
> stream of ES6, because with modules we go from a splat of script tags, to a
> universe of connected systems.
>
> Finally, there are actual use cases which require lexical modules.  Let's
> say that I want to develop a library where each module lives in its own
> source file.  And let's say that I only want to expose a "main" module, and
> hide the rest.  Without lexical modules, there is no straightforward build
> process capable of encapsulating those internal modules.
>
> { Kevin }
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130415/1d1fcd81/attachment.html>


More information about the es-discuss mailing list