simple modules

Sam Tobin-Hochstadt samth at
Tue Feb 2 12:19:41 PST 2010

On Tue, Feb 2, 2010 at 12:19 AM,  <ihab.awad at> wrote:
>See previous; hope that clarifies.

Ihab -

[responding to a bunch of messages together]

I think I now have a better grasp on your concerns, so I hope I can
give a better answer.  It seems like the primary concerns are twofold:

1. Since modules are stateful, how can a secure subset avoid
inadvertently creating communication channels between modules.
2. Since the module system provides a global way to name modules, any
module can name powerful, stateful, modules provided by the host

Is that a reasonable characterization?

I'll try to address each of these points in turn.

First, there's a simple subset of module system which (I think) meets
ocap criteria.  Simply consider only modules which have no 'top-level'
state, that is, that do not mutate any state that is created by simply
executing the module.  For example, the counter module example Dave
gave (now on the wiki) doesn't have any top-level state.  Programming
in this subset is not as convenient, but it certainly avoids any
shared state or inadvertent communication.  And it allows the same
patterns that are available in Emaker-style modules.  I don't think
that this is devolving into the Turing Tarpit.

Unfortunately, that story only works for pure ES code, and doesn't say
anything about how to program in an ocap style with stateful modules
provided by the host environment. Further, even if the host only
provided functions that would be invoked, a module in ES could still
invoke that function and thus allow access to the powerful host

The primary solution here would be to set up a restricted Context
which restricted access to particular stateful modules (this of course
works for all stateful modules).  You've described this as a
heavyweight operation, but I hope we can make it convenient enough not
to be a barrier to use.  You've also said that you don't think it can
be used for fine-grained authority, but I don't see why not.

Further, if SES is the subset described earlier, with access only to
stateless modules, along with stateless versions of the host modules,
then it seems possible to program in a perfectly ocap style in this

Does that make sense?
sam th
samth at

More information about the es-discuss mailing list