simple modules

Mark S. Miller erights at
Tue Feb 2 13:11:44 PST 2010

On Tue, Feb 2, 2010 at 11:24 AM, Brendan Eich <brendan at> 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 <>, 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

See <> and <> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list