ModuleImport
C. Scott Ananian
ecmascript at cscott.net
Fri Jun 27 12:45:32 PDT 2014
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>
More information about the es-discuss
mailing list