Composition of Uncoordinated Working Sets of Modules

Brendan Eich brendan at
Sat Jun 5 14:41:00 PDT 2010

On Jun 5, 2010, at 2:17 PM, Kris Kowal wrote:

> On Sat, Jun 5, 2010 at 3:40 AM, Sam Tobin-Hochstadt  
> <samth at> wrote:
>> On Fri, Jun 4, 2010 at 9:48 PM, Kris Kowal <kris.kowal at>  
>> wrote:
>>> On Fri, Jun 4, 2010 at 5:17 PM, David Herman <dherman at>  
>>> wrote:
>>>> By keeping modules second class, we get a number of benefits, not
>>>> just handling cyclic dependencies. (In fact, cyclic dependencies  
>>>> can
>>>> be handled nicely in a first-class module system as well.) One of
>>>> the benefits of second-class modules is the ability to manage  
>>>> static
>>>> bindings; for example, import m.*; is statically manageable. Allen
>>>> has made some good points about how second-class modules are a good
>>>> fit for the programmer's mental model of statically delineated
>>>> portions of code. At any rate, cyclic dependencies are not the
>>>> central point.
>>> As far as I can tell, Simple Modules only changes the composition
>>> hazard introduced by "imoprt m.*" from a run-time hazard to a
>>> link-time hazard.
>> In your example, certainly the earlier error is a benefit of our
>> proposal.
> I strongly disagree.

Whoa -- I don't see how anyone can disagree that early error is better  
than a runtime error, if there is an error case at all. It seems to me  
you're instead arguing that no such error should be possible because  
import m.* should not be supported -- that you're arguing against any  
import-everything-that's-exported feature. Right?

>  Either Alice is at fault for using "import m.*",
> Charlie is at fault for altering her API, or neither Alice and Charlie
> are at fault because they were merely and earnestly using the features
> of the underlying system, in which case the system is at fault.  Alice
> should be able to trust the features of her module system.  Charlie
> should be able to *augment* her API without breaking her dependents.

The only reason import m.* is in the proposal is that when one is  
using modules in one's *own* (definitely including the single-author  
case, but also the single-curator and same-origin-hosted case) larger  
program, where the hazard of new names can be controlled by testing  
and auditing, then lack of import m.* is a royal pain. This is  
especially true during rapid prototyping.

If * imports were considered too dangerous because they might be  
abused at scale and across administrative boundaries, then they could  
be dropped. This is a sideshow -- it doesn't get at the essential  
issue of second- vs. first-class module system, or other seeming bones  
of contention.

But I don't think there's a consensus to drop * imports. Lots of  
things in JS can be abused, but are not so hazardous they should be  
removed. True,'with' is gone in ES5 strict, eval is tamed somewhat.  
Perhaps there's a case for a future stricter strict mode forbidding *  
imports, but it's not obviously worth the added modal complexity.

>> But the really key benefit is this:
>> module M {
>>  export x = 7;
>> }
>> module N {
>>  M.y + 3; // an error - just like an unbound variable in ES5 strict
>> }
> This feature does not preclude the omission of the import * syntax
> variant.

Right -- no one is saying * imports must be part of the system to keep  
other aspects of the design working. And singling out * imports does  
not argue against the whole design.

>> This can be an early error because we statically know a lot about
>> modules.  This is good for programmers, because it supports early
>> errors, and also good for compiler writers, since it supports
>> optimization.
> I agree.  I do not think that any of my objections preclude statically
> linking name spaces.

Ok, then it seems you did agree earlier too, that an early error is  
better than a runtime error. Whew!


More information about the es-discuss mailing list