On Tue, Feb 2, 2010 at 11:24 AM, Brendan Eich <bren...@mozilla.com> wrote:
> On Feb 2, 2010, at 10:58 AM, Mark S. Miller wrote: > > In particular, it would be bizarre for Harmony to have two distinct and >> disjoint module systems, A and B, simply because module system A was >> unnecessarily inappropriate for the ocap subset. >> > > No one is proposing this. It would be bizarre. It's a false dilemma. > Good; this is clarifying. I'm glad no one is proposing that. > 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. But > I'll let others say more. Perhaps other's aren't seeing the problem with A that I am seeing: mutable static state. In ocap languages < http://wiki.erights.org/wiki/Object-capability_languages>, when modules X and Y both import module Z, that must not by itself provide a communication path between X and Y. This is known as the "mutable static state" problem. If a module instance can contain mutable static state, and if X and Y obtain shared access to the same Z instance merely by importing it in a shared loading context, then communications channels become implicit and not practically deniable. My apologies for still not having caught up and so possibly still missing some context. But from chatting with Ihab and Tom, it seems the subset of your proposal where an SES loader enforces that it only loads modules which export only transitively immutable values would be ocap-friendly, and would be (perhaps modulo details) within a subset of the 2nd class module proposal. See <http://gbracha.blogspot.com/2008/02/cutting-out-static.html> and < http://www.cs.berkeley.edu/~daw/papers/joe-e-ndss10.pdf> for many software engineering benefits of avoiding mutable static state. As Gilad says, Given all these downsides, surely there must be some significant upside [to mutable static state], something to trade off against the host of evils mentioned above? Well, not really. It’s just a mistake, hallowed by long tradition. Which is why Newspeak has dispensed with it. If Gilad is right, then it is a mistake for Harmony as well. I believe it is. But as long as Harmony's module system admits a subset which enforces the absence of static state, I'm happy enough. > Since SES needs an ocap-compatible module system, and since this module >> system must be within a subset of Harmony, it makes more sense to me to >> start with the more constrained problem: Let's design a module system B >> adequate for the needs of both SES and Harmony. Once we understand the shape >> of that, then we can reexamine whether Harmony still needs a second >> insecurable module system, or merely an insecure superset of the secure >> module system. >> > > Sorry, this is too biased and path-dependent a design approach. The space > we are "searching" is large. We need to consider alternatives at both > layers, and where possible avoid too much layering. > > Layering is a problem, not a solution. > I wholeheartedly agree. If we can design a single module system that can solve all these needs without layering, that would be awesome. I sincerely hope we can. > /be > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
