Modules first or second class (Re: I noted some open issues on "Classes with Trait Composition")
dherman at mozilla.com
Fri May 20 15:37:11 PDT 2011
Yep! By making modules static, we introduce much cleaner ways of sharing constants. Responding to Claus in a sec...
On May 20, 2011, at 3:21 PM, Kam Kasravi wrote:
> This is sort of an interesting point. In a related question I've wondered about how narcissus could use modules in lieu of
> its current way of eval'ing definitions.const in jslex and jsparse in order to get the operators, tokens and keywords in local scope
> for both the lexer and the parser. If narcissus were to take advantage of harmony could jsparse, jslex do an 'import jsdefs.consts' as an alternative?
> From: Claus Reinke <claus.reinke at talk21.com>
> To: David Herman <dherman at mozilla.com>
> Cc: es-discuss at mozilla.org
> Sent: Friday, May 20, 2011 2:51 PM
> Subject: Modules first or second class (Re: I noted some open issues on "Classes with Trait Composition")
> > 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,
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss