ModuleImport

Andreas Rossberg rossberg at google.com
Mon Jun 30 04:14:35 PDT 2014


On 27 June 2014 21:45, C. Scott Ananian <ecmascript at cscott.net> wrote:
> On Fri, Jun 27, 2014 at 3:34 PM, Andreas Rossberg <rossberg at google.com>
> wrote:
>>
>> All this means is that there will effectively be two different module
>> systems, and in practice, every module provider has to pick one. Which
>> is a problem, not a solution.
>
> ...this is why I've been arguing strongly for consistent syntax regardless.
> Static checking and lazy binding should be "value added features", not
> something I have to think about every time I import a module.

Painting over semantic differences by using the same syntax is not an
improvement in usability. It decreases readability, and increases
confusion and surprise. You probably weren't around when this was
discussed last time, but the differences between importing from a
"proper" module and importing from a singleton export object are not
just in static checking. They create different bindings. The former
creates an _alias_ for the variable from the module. The latter would
need to destructure the property into a _new_ variable, i.e., would
need to _copy_ its state. This leads to visibly different results when
the variable is mutated (internally or externally).

Please assume that all these ideas have been discussed extensively,
and carefully considered, in particular by Dave and Sam. And while I
do not agree with all conclusions, the current design has gotten much
more thought in it than many in this thread seem to assume. In
particular, none of the suggestions made in this thread so far are
new.

>> >> The hybrid, best of both worlds approach you seem to
>> >> have in mind is technically impossible, unfortunately.
>> >
>> > I look forward to a technical proof then.  You have not yet provided
>> > that.
>>
>> Well, I don't know how it could be done. I think the proof obligation
>> is on those who claim it's possible. ;)
>
> jslint/jshint is already a (hacky) proof for the most common cases.  It
> detects undeclared variables.  All you need to do is write a loader which
> will prepopulate the jshint's 'predef' field appropriately.
>
> More complicated sorts of static checking fall to Turing completeness.  Ie:
>
> ```
> import foo from "foo";
>
> var bat = (Math.random() & 1) ? foo : { };
>
> console.log(bat.baz); // is this a static error?
> ```
>
> The reasonable thing is to accept incompleteness and provide static checking
> of the common cases: barewords and <module name>.<identifier> productions.
> Both of those tests are quite capable of skipping tests if <module name> is
> not a "pure" module.

And that is exactly why "real" ES6 modules are more structured. They
are carefully crafted such that checking of imports/exports is
_always_ possible. And as I said earlier, any attempt to make them
interchangeable with legacy-style modules would break this property.

We can decide that this checking is not worth it and drop it. But we
cannot have our cake and eat it too.

/Andreas


More information about the es-discuss mailing list