simple modules

[Kevin Curtis]

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
...

On Tue, Feb 2, 2010 at 8:48 PM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>wrote:

> On Tue, Feb 2, 2010 at 3:12 PM,  <ihab.awad at gmail.com> wrote:
> > On Tue, Feb 2, 2010 at 7:24 PM, Brendan Eich <brendan at mozilla.com>
> wrote:
> >> On the other hand, the second class "simple modules" proposal, plus the
> >> impending Context proposal, allows A and subset-A, as far as I can tell.
> >
> > Yes, it allows subset-A by the creation of new Contexts.
>
> New Contexts are necessary only in the case where there are some
> stateful modules whose access needs to be restricted.  Note also that
> new Contexts are also necessary for programming in an ocap manner in
> the primordials module system strawman as demoed by Kris at the most
> recent TC39 meeting.  For example, I think he showed an example like
> this:
>
> var FS = require("fs");
> FS.open("myfile");
>
> Here we again have a global namespace, giving access to powerful,
> stateful code, accessed by the `require' function, which is
> potentially restricted by using a Context to change the behavior of
> `require'.  (If I've misunderstood what the code Kris presented did,
> please let me know.)
>
> The alternative is to pass all state explicitly.  This is (I think)
> what the Emaker-style proposal does.  This has the following important
> drawbacks:
>
> 1. It means that the *only* way to program modularly is to use the
> stateful-object-passing style.  Since this is less convenient for many
> use cases than simply mutating the global object as in current ES,
> programmers are less likely to use modules.
>
> 2. If we persuade programmers to use modules, they're likely to pass
> around overly-powerful objects, making reasoning about security
> harder.  A module which takes a single parameter named 'global' and
> performs all its operations by mutating this object is much harder to
> reason about than one which imports numerous modules, a few of which
> are stateful.
>
> > The result is not a "capability language" as commonly understood; the
> > language constructs by themselves are not _prima facie_ usable to
> > implement ocaps. The result is rather more akin to a capability
> > operating system, in which somewhat coarse-grained units of trust
> > share information freely among themselves, while having limited
> > authority at their boundaries.
> >
> > If TC39 wishes to construct such a system in lieu of a capability
> > *language* in SES, the committee needs to achieve concensus on this
> > issue first -- and update the wiki! -- before commissioning module
> > proposals.
>
> I'm surprised that you don't think this qualifies as a capability
> language. ES + the simple modules proposal seems to me to be just as
> much a capability language as the language and module system in
> Jonathan Rees' dissertation.
> --
> sam th
> samth at ccs.neu.edu
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100203/955ce66f/attachment-0001.html>