Simple Modules and Current Modules

Kris Zyp kris at
Thu Nov 4 09:46:02 PDT 2010

Hash: SHA1

On 11/4/2010 8:02 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Nov 4, 2010 at 9:22 AM, Kris Zyp <kris at> wrote:
>> I believe it should be a requirement that harmony
>> modules (or at least a subset of them) should be desugarable into ES5
>> code, such that the desugared code is still a working module in
>> harmony engines that support native modules.
> I think that this requirement would mean that modules in Harmony would
> be unable to provide all of the things we want - in particular, true
> lexical scoping of modules and the names they export and import.
For imported names, I don't understand why lexical scoping fails to
work just because a function call is involved. For exports, I thought
the key to linking was freezing objects, which is readily available in

> [lots on the integration of modules with existing systems]
> I think the area of integration with the work people are already doing
> in RequireJS, CommonJS, Dojo, and other systems is very important. As
> the Simple Modules proposal continues to evolve, Dave and I will work
> hard to make this integration and future migration as easy and
> transparent as possible.
That's to great to hear. My objection below is due to the fact that I
currently don't see how this proposal brings an integration path with
real benefits to existing module systems or provides a compelling
alternative to them (other than the security benefits of lexical
scoping and improved eval, which is awesome). If it I could be
illuminated on the benefits and how to deal with the problems I
mentioned, I am sure I would be more favorable towards it.

> But,
>> At least in the area of modules, if we focused on small composable
>> feature(s) that are truly needed to build module systems on top of
>> EcmaScript, we can introduce a much simpler addition, and ensure that
>> we get it right, yet still provide the build blocks for modules with
>> security.
> I strongly disagree with this. There is no consensus whatsoever as to
> what those "small composable features" are.
Of course not, I just suggested it! Are you suggesting that reaching
consensus on large complicated features is easier than small simple

> Further, there is no
> precedent in other programming languages for building modules out of
> other features, especially not using runtime evaluation.

What about EcmaScript!? All current JS module systems build on
existing features.

> I think that
> trying to be way out in front of the rest of programming language
> world in this area would be a mistake.
This isn't out in front, quite the opposite, I am suggesting
conservative steps forward.
>> Namely, the true nugget from the module system is the
>> ability to evaluate scripts with lexical scoping, and ensure a real
>> filename is associated with the script (for real stack traces,
>> debugging, etc).
> I disagree that this is the "true nugget". Modules are about much
> more than 'eval', and certainly much more than associating a "real
> filename" (hopeless in the general case anyway).

Of course there is much more. But from real-world use of today's
module systems, this is one of the key missing build blocks.

- -- 
Kris Zyp
(503) 806-1841
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -

More information about the es-discuss mailing list