I don't really think that "module state" should be a formal concept in a "second class" module system where modules are just units of static code organization. Such modules have little if anything to do with computational state. It is the declarative and imperative code within the module that creates and binds state. Modules, via import and export declarations, can cause identifier bindings to be shared but that says nothing about the "ownership" of the actual computational values that are accessed via those bindings.
It may be conversationally convenient to use the term "module state" to talk about the computational values and binding created by the code within a module but it really shouldn't mean anything much different from saying the "the state of source code lines 243-619" (caveat, I'm ignoring module initialization order issues above but even that are more about temporal validity of bindings rather than the actual bound state.) Allen From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Curtis Sent: Wednesday, February 03, 2010 11:11 AM To: Sam Tobin-Hochstadt Cc: Mark S. Miller; [email protected]; Brendan Eich Subject: Re: simple modules Is there a fundamental theoretical comp sci reason why module state is shared? Is the core idea of using lexical scoping in the simple_module proposal undermined by not having shared state. If not, could possibly non-shared state be the default behaviour. And shared state modules - which share state within contexts - are somehow marked as shared at module definition. e.g. module ModShared { "use shared" // or some mechanism to signify shared state ...
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
