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

Brendan Eich brendan at mozilla.com
Fri May 20 15:13:23 PDT 2011


On May 20, 2011, at 2:51 PM, Claus Reinke wrote:

>> I think "modules are a construct that evaluates to an object" is the wrong way to think about them. Syntactic modules are a second-class construct that is not an expression. You can reflect on modules at runtime, and that reflection is provided as an object, but that's because almost all compound data structures in JS are objects. But I would advise against describing modules as a kind of object.
> 
> Just a note on this: for me, that means Harmony modules
> are a step back from what I can implement in JS/now.

That's false, since you cannot implement what second class modules provide in JS now without a preprocessor. You cannot, by special forms such as the module M = ... form, tell the compiler to prefetch or find memoized a certain module.


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

Yes, the CMU folks were buggin'. But: please try to look at JS as it is, not just reference Haskell.


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

Why?

If you want first-class objects, use objects (frozen if you like). If you want functions, they're in JS already.

Generative classes by nesting in a maker function fall out cleanly from this design.


> Is this an intended outcome of the Harmony module design?

Please read the proposal page.

http://wiki.ecmascript.org/doku.php?id=harmony:modules

It's all there: static scoping, orthogonality, etc.

/be


More information about the es-discuss mailing list