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 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
