[Sorry about the wide distribution of this message. Please direct replies to an appropriately narrower audience -- probably modules@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@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@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@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.