Modules first or second class (Re: I noted some open issues on "Classes with Trait Composition")

David Herman dherman at
Fri May 20 15:55:51 PDT 2011

> Just a note on this: for me, that means Harmony modules
> are a step back from what I can implement in JS/now.

How is it a step back, if you can already implement it? We're not taking objects away from JavaScript.

> Not
> having first-class modules has been a major drawback in
> Haskell (which has a strictly 1980s-style module system),
> leading to all kinds of work-arounds. 

Usually when people deride the Haskell module system, they are comparing it to the ML module system, which... is also a second-class module system.

> One of these workarounds, which I expect to see and use
> a lot in Harmony, is to have first-class modules-as-records
> (or objects) inside second-class built-in-modules.
> Is this an intended outcome of the Harmony module design?

That's kind of a loaded question, given the word "workaround" but yes, it's definitely an intended outcome of the design to have second-class modules. Modules that are second-class have many benefits over first-class modules:

- they are extremely lightweight, which is really important for ergonomics

- they make it possible to do compile-time linking and variable resolution

- they can share static information, such as sets of bindings (not that import * would not work with first-class modules), macros, or types (both of which are, IMO, worth considering in the future for ECMAScript)

Moreover, loaders make it possible to do dynamic linking. It's just a little harder than in e.g. SML. I say that's the right trade-off: writing simple modules is trivial, and writing modules with pluggable dependencies is still possible.


More information about the es-discuss mailing list