ModuleImport

[C. Scott Ananian]

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.

>> 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.
 --scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140627/dc6a232f/attachment.html>