ES Modules: suggestions for improvement

[Isaac Schlueter]

On Wed, Jun 27, 2012 at 9:39 AM, Brendan Eich <brendan at mozilla.org> wrote:
> First, what we propose is not type-checking.

Oh, ok.  I misunderstood.  Let's not say another word about type checking :)


> var foo = 42;
> ... foop ...
>
> throws at runtime in ES1-5 if evaluation reaches the foop use, and (if you
> wrap a module around that hunk of code, and there's no global foop property)
> at compile-time (EarlyError) in ES6.

I don't think that's a real problem.  Can you point to in-the-wild
bugs caused by this?  Maybe it's a failure of imagination on my part.

The "cost" I was referring to was:
1. added syntax
2. less obvious-for-humans-to-read programs

Consider:

module "foo" {
  export let x = 100;
  export let y = { z: 'zed' }
}

// far far away in another file entirely...
import * from "foo";
import * from "baz";
console.log(x) // what?  where did THAT come from?
x++; // do other importers of foo see x change? if so, spooky! if not,
why not? is it foo's x or not?
y.z = 'zoo' // surely that must be shared, right?

The compiler knows about x, but I don't.  This is probably my biggest
complaint about using C and C++.  Managing exported symbols is not
hard to automate, but it is hard to not-automate, and that makes it
more painful than just fixing the bugs.  Compare with:

var foo = import "foo";
console.log(foo.x) // maybe undefined, but so what?

We deal with undefined properties of objects all the time, and it's
not really such a big deal.  Typos are not a problem worth giving up
"export one thing" semantics for, and dealing with symbol conflicts is
worse.  Just let me call my vars whatever I want; when I ask for your
thing, give me your thing.  Dumping a bunch of symbols into my local
scope is intrusive.


> Second, you are "not at all convinced". Ok, that's either attitudinizing and
> padding an already long reply, or a line in the sand that doesn't say how
> you would be convinced, so unanswerable.

Sorry, you're right, that was unclear.

I would be convinced by examples showing bugs in modern programs that
would have been prevented by the proposed static export syntax.  Ie,
bugs that current state of the art module systems do not or cannot
address, and which are causing actual problems.


> We will never agree on "what JS is all about".

Well, apparently we do wrt static type checking, actually :)

But you're right.  I'll leave esthetics out of it.  Let's focus on practicality.


> You seem to say lack of typo checking is not a gap in the language. Is this
> a fair statement?

Yes that is a fair statement.  I don't see how we can add typo
checking without also adding "you get to tell me what to call my local
vars".  In every other place in the language, I get to decide what my
vars are called, and typo-checking happens locally, not at a distance.
 That's not a gap, that's a feature.

The main gap in the language that I'd like to see filled by a
module/loader spec is global leakage.  As I see it, the rest is simply
"how do we do that, without also removing module communication".
Removing global leakage removes global communication, so in
module-mode, we need a way for modules to communicate to one another,
and for the host system to know which programs to load.