Modules feedback from March 2013 meeting

Andreas Rossberg rossberg at
Tue Mar 26 03:23:34 PDT 2013

On 25 March 2013 18:31, James Burke <jrburke at> wrote:
> ### Single Anonymous Export ###
> The latest update was more about semantics, but some thoughts on how
> single anonymous export might work:
> Just use `export` for the single anonymous export:
> module "m" {
>     export function calculate() {}
> }
> where calculate is just the local name for use internally by the
> module, but `calculate` is not visible to outside modules, they just
> import that single anonymous export.
> For exporting a named property:
> module "n" {
>     export calculate: function () {}
> }
> This would still result in a local `calculate`, let-equivalent local
> name, but then also allows for other modules to import `calculate`
> from this module.

And how about const declarations, class declarations, module
declarations, and any other declaration form that might enter the
language at some point? I can't see how your suggestion scales to

Also, optimising the entire syntax for one special use case while
uglifying all regular ones will be a hard sell.

> ---- start extremely speculative section:
> This next part is very speculative, and the most likely of this
> feedback to be a waste of your time:
> "crypto" is a bit more interesting. It would be neat to allow:
> let { encrypt } from "crypto";
> which is shorthand for:
> import temp from "crypto";
> let { encrypt } = temp;

You are trying very hard to avoid using ES6 modules the way they are
meant to be used. Just define your crypto module as

 module "crypto" {
     export function encrypt() {}
     export function decrypt() {}

and the existing import destructuring will work like a charm, while
having made your module both prettier and more concise. ;)

> With that capability, it may be possible to go without `import` at
> all, at least at this stage of ES (macros later may require it).

As I have explained earlier on this list, destructuring import and
destructuring let are not the same. The former introduces aliases, not
new stateful bindings. This is relevant if you want to be able to
export mutable entities. So no, we cannot drop import.

> Going even further: then the `export publicName: value` syntax may not
> be needed either.

Only when you're willing to throw all static checking (not just of
imports but any module access M.x) out the window.

> ### Nested modules ###
> This was explicitly stated as a non-goal, but it is something that
> shows up in the AMD module world (library builds with almond wrapped
> with a UMD style boilerplate for use by the outside world):
> module "publicThing" {
>   module "j" {}
>   module "k" {}
>   export …. //something visible outside publicThing
> }
> The idea being that internally "publicThing" uses some modules, but
> they are only for its internal use, not for use outside of
> "publicThing".
> It would be nice to allow a chain of ID lookup tables, favoring a
> local lookup table/closer tables and working up the chain to find a
> match. If no match, a module is fetched/loaded and placed in the top
> level table.

I agree with your goal, and that is why I still maintain my point of
view that modules should be denoted by regular lexically scoped
identifiers, like any good language citizen. Then we'd get the right
rules for free, in a clean, declarative manner, and wouldn't need to
reinvent the wheel continuously, through more and more operational


More information about the es-discuss mailing list