Simple Modules and Current Modules

Sam Tobin-Hochstadt samth at ccs.neu.edu
Thu Nov 4 07:02:38 PDT 2010


On Thu, Nov 4, 2010 at 9:22 AM, Kris Zyp <kris at sitepen.com> 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.

[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.

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.  Further, there is no
precedent in other programming languages for building modules out of
other features, especially not using runtime evaluation. I think that
trying to be way out in front of the rest of programming language
world in this area would be a mistake.

> 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).
-- 
sam th
samth at ccs.neu.edu


More information about the es-discuss mailing list