[Sorry about the wide distribution of this message. Please direct replies to 
an appropriately narrower audience -- probably 
modules at lists.squeakfoundation.org .]

Cees de Groot wrote:
> I'm not sure how many subscribe here that do not subscribe or actively  
> follow squeak-dev, but a team is forming to work towards a short-term  
> 'modules' thingy for Squeak.

I lurk, sort-of, but the volume of traffic is overwhelming, so I don't even 
read it as it goes by. Below, you mention a separate list for discussion of 
modules -- modules at lists.squeakfoundation.org. I suggest that the discussion 
of modules should indeed move there, if you want the attention of people too 
busy to read squeak-dev.

Is the intention of this thread to fix the main problem preventing the 
creation of a Squeak-E -- a capability secure variant of Squeak? By "main 
problem", I mean the pervasive use of widely shared (effectively global) 
namespaces and state. If so, perhaps Squeak-E is the right forum, and perhaps 
we don't need yet another new list?


> Dan Ingalls leads the team, and he wants 
> to  implement The Simplest Thing With The Largest Impact - which means 
> that he  is looking at stuff like E, Vats so that modules could have 
> security  implications (implications in the positive sense).

The E Vat concept and the E module concept are mostly orthogonal.

                            Vats

Each Vat runs a singly threaded event loop -- a Vat is an island of synchrony 
in a sea of asynchrony. Vats form an address-space-like disjoint partitioning 
of objects, where the live references that may cross between vats may only be 
"eventual references" -- references that may only carry eventually-sent 
messages, so that Vats can only be asynchronously coupled to each other.

Inter-Vat references are also the only kind that may spontaneously break. 
Breakage can be caused by network failure, crash, or killing a Vat -- the Vat 
is thereby the unit of partial failure and resource eviction.

With these two properties, the Vat is also the largest sensible unit of 
identity-preserving separable persistence, and therefore of migration. 
Smalltalk's orthogonal persistence system is great, and I look forward to 
having it underneath E-on-Squeak. However, this doesn't solve the separable 
persistence / migration problem. Both Smalltalk and E handle the separable 
persistence problem by serialization.  This is where we should look for a 
bridge between the E Vat concept and the E module concept.

At http://www.erights.org/data/serial/jhu-paper/index.html , I give a sketch 
of a user-level serialization system for E, where this serialization system is 
1) able to provide per-Vat or finer persistence, and 2) where this 
serialization system is based on "un-evaluation", i.e., where the serialized 
form of an object graph is an expression, and unserializing is just evaluating 
this expression.

                       Eval & Modules

The current E module system is provided as a primitive part of E, but should 
instead be built up from eval, and hopefully will be in future implementations 
of E. See p8 of http://www.erights.org/talks/asian03/paradigm-revised.pdf for 
a precise statement of the security properties that eval must satisfy. (That 
document uses the term "loader" for the eval function.) We thereby unify 
loading and unserialization -- they are both simple uses of expression 
evaluation. (Oz & Oz-E unify unserialization and module loading in essentially 
this way as well.)

I don't like the current E module system, and I have various thoughts about 
how to change it. However, they all have in common 1) that they are built, 
without cheating, on an eval with the security properties explained in the 
above document, and 2) that module import may lead to shared identity, but not 
shared state. What does this mean?

Suppose A and B both import name "C" from loader L. In the current E module 
system, the text of C is as-if evaluated afresh each time, and so and 
identities or state created by C is created separately for each of its 
clients, A and B. A and B cannot come to have a communications channel to each 
other merely by having shared access to the loader L, and by having asked L to 
import the same module name, "C". The problem with this approach is that any 
identities exported by C are not shared by A and B, preventing them from 
comparing such identities in order to talk to each other about C-stuff. For 
example, "x isKindOf: C" may be pointlessly picky.

I think, instead, each loader should load a given module name exactly once, 
where the resulting module values are required to be DeepFrozen (transitively 
immutable). This still gives us multiple instantiation of created identities, 
by virtue of creating multiple first class loaders. But it separates the 
relatively-safe sharing of identities from the relatively dangerous sharing of 
state. In the approximation that the source of loaded modules is itself 
immutable (in E-on-Java, if the classpath and its contents are immutable), 
then each loader can be considered immutable. By enabling two entities to 
share access to loader L, we enable them to share imported identities, but not 
thereby to interact with each other.

In the Smalltalk context, where development happens primarily within a single 
persistent system image, rather than by loading module files from a file 
system, all these issues may look quite different. I don't yet have any clear 
idea how to think about these differences.

(The BitC language has adopted the safety portion of this rule corresponding 
to use of a single shared loader. See section 6.1 of 
http://www.coyotos.org/docs/bitc-spec/bitc-spec.html .)


> Anyway, there's a mailing list  
> (modules-subscribe at discuss.squeakfoundation.org) and a Swiki page to  
> discuss this all (http://minnow.cc.gatech.edu/squeak/5608) so if you 
> think  you've got something to add from the E perspective, this is 
> probably The  Chance.

What's the relationship between http://lists.squeakfoundation.org/listinfo and 
http://discuss.squeakfoundation.org/ ? I see the first lists Squeak-e but not 
modules, while the latter lists modules but not Squeak-e.

When I click on the "Modules" link on http://discuss.squeakfoundation.org/ , I 
get a
> Internal Server Error
> 
> The server encountered an internal error or misconfiguration and was unable to
> complete your request.
> 
> Please contact the server administrator, webmaster at localhost and inform them
> of the time the error occurred, and anything you might have done that may have
> caused the error.
> 
> More information about this error may be available in the server error log.
> Apache/2.0.52 (Debian GNU/Linux) DAV/2 SVN/1.1.3 Server at
> discuss.squeakfoundation.org Port 80


Everyone, please remember to respond to a narrower audience. Thanks.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM