Andreas Rossberg rossberg at
Fri Jun 27 12:34:19 PDT 2014

On 27 June 2014 21:26, C. Scott Ananian <ecmascript at> wrote:
> On Fri, Jun 27, 2014 at 3:17 PM, Andreas Rossberg <rossberg at>
> wrote:
>> I think you are missing the central problem. If imports/exports are to
>> be statically checked, then module bindings, their exports, and their
>> uses have to be statically recognisable and analysable. That prohibits
>> intermixing "proper" modules with other random objects.
> No, it means that your checker will only work with 'proper' modules.  The
> linter can easily have a white/blacklist to handle oddball cases.
>> You argue that throwing out checking is fine, i.e., you are arguing
>> for the second goal, and against the first. But others disagree.
> No.  I believe that *allowing the user (or module author) to selectively
> ignore* the checking (for example, by using a default import of an object
> which is not a module).  You seem to be missing my fundamental point: this
> is not a dichotomy.  You can check many imports, even if you can't check
> all.  If the module author chooses to export a function instead of an
> object, you can't check the imports of *that one module*.  Use a different
> module if that bothers you!
>> No, the importers have no choice, they have to go with whatever the
>> module provider picked.
> The importers have the choice to use a different module (or fork the module,
> or use a transpiler, or...).
> The module author has the choice to re/structure his module to allow lazy
> binding/checking *iff the users demand*.

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.

>> 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. ;)


More information about the es-discuss mailing list