Re: More flexibility in the ECMAScript part?

> Agreed. Further, ES can't avoid specifying event loops, perhaps even in an
> ES6 timeframe!! It would indeed be unfortunate if we need to specify this
> in ES6. But I don't see how we can specify module loaders without doing so.
> The only alternative I see is that we postpone module loaders till ES7,
> which many of us (including myself) would find unpleasant.
>
>
Another upside would be easing the near-term workload on TC39 (and Allen
most of all).

Although I do not want to see module loaders postponed till ES7, for
> completeness I will mention one further advantage of doing so. Currently,
> module loaders are specified in terms of callbacks. Were they postponed, we
> could instead specify their API in terms of promises. The similarity to the
> spec dependency dilemmas motivating this thread are indeed striking.
>

Part of the problem is that hitherto the core standard library and platform
library (DOM) share the same namespace.  As such, any activity in this
shared namespace has an oversized influence on other designers.  Perhaps
modules can rectify this situation.  What if, going forward, DOM APIs were
homed in their own module namespace?

    import Future from "dom:future";

    let future = new Future({ resolve, reject } => resolve("Anne rocks!"));

I would probably leave the standard core library in the global lexical
namespace:

    let promise = new Promise({ resolve, reject } => resolve("Mark
rocks!"));

There is still a clash, to a certain degree, but the effects are much more
localized.

{ Kevin }