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. 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.
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?
For instance, I've got a parser-combinator library and
a (near) ES5 grammar built on it, and to test, I pass one
module to the other, and both modules to the tester:
test(source, options, pc, grammar(pc))
Strictly speaking, the pc module also depends on the
grammar module, for grammar-specified whitespace,
but cyclic structures are a bit awkward in Javascript.
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
