Modules first or second class (Re: I noted some open issues on "Classes with Trait Composition")
Claus Reinke
claus.reinke at talk21.com
Fri May 20 14:51:14 PDT 2011
> 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
More information about the es-discuss
mailing list