Modules first or second class (Re: I noted some open issues on "Classes with Trait Composition")
dherman at mozilla.com
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.
> 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