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

[Claus Reinke]

> 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