[Squeak-e] Draft Consensus Plan

Mark S. Miller markm at caplet.com
Sun Feb 9 18:45:18 CET 2003

Between the replies by Dean, Cees, Joshua, Andreas, and Rob, I see a lot of 
agreement and convergent thinking. Before replying to the individual posts, 
I thought I'd first try drafting a set of high level points, plans, and 
milestones that we could refine into something we're all in general 
agreement with. Oh, plus a bit of a twist at the end. Please fire away.

* Squeak-E and Squeak are to be two similar but different languages -- both in 
terms of core language and standard libraries. Neither one is upwards 
compatible from the other, but we expect and hope that they'll be similar 
enough that much ordinary vanilla non-meta code may be able to be ported in 
either direction with little manual effort.

* Squeak will be unchanged in its security status: All Squeak code in an 
image is assumed to be able to wield all of their user's authority. All the 
user's interests are fully vulnerable to -- at the mercy of -- all their 
Squeak code. (In the jargon, all code written in Squeak is part of the 
user's "Trusted Computing Base", or TCB.)

* The CapTP effort ('A Functioning Interim Vat') to build a library for 
speaking a cryptographic capability protocol brings the power of inter-image 
capabilities both to Squeak and Squeak-E. It adds value to Squeak whether or 
not Squeak-E ever happens, and is tremendously synergistic with Squeak-E if 
it does happen. This is analogous to CapTP/ELib being quite usable (and 
used!) from Java, though CapTP is strongly integrated only with the E 
language. The CapTP effort is therefore an excellent early milestone with 
few dependencies.

* Squeak and Squeak-E will run alongside each other in the one image, and be 
able to directly point at and call each other's objects. Squeak-E 
code will only be able to access a tamed subset of the methods defined on a 
Squeak object -- those in accord with capability discipline. (Note: I like 
Andreas' selector renaming approach better than my 2-method-dictionaries 
approach, about which more later.)

* Although we don't yet know for certain what we may want to change in the 
existing Squeak system to better support the Squeak-E effort, we can be 
confident that all these changes will be upwards compatible to essentially 
all Squeak code, including browsers, debuggers, and various meta tools as 
applied to Squeak objects.

* Squeak-E is to be designed for security ambition level 4: able to support 
unprivileged security abstractions. (As another inadequacy of my initial 
draft taxonomy, these levels don't say anything about self-debuggability or 

* We wish to eventually get back to something like Smalltalk's extraordinary 
self-debuggability or self-malleability in a self-sufficient way, where 
these tools are themselves written in Squeak-E and therefore subject to 
capability discipline. I think this can be done eventually (as in the 
Safra/Shapiro virtualization layers), but it's hard, and if it's included in 
the first bite, that first bite will be too big to chew. (Note that E is at 
level 4, but without yet any self debuggability or self-malleability.)

* People are understandably attached to their access to Smalltalk's 
extraordinary self-debuggability or self-malleability, as embodied in the 
browsers, debuggers, etc. My initially proposed direction of starting 
Spartan and then building back up to a well supported programming 
environment would have lost our audience.

                           The Twist

* What if, as a bootstrapping strategy, Squeak-E starts out not
self-debuggable and self-malleable, but rather debuggable-by-Squeak-code and 
malleable-by-Squeak-code? In other words, the browsers and debuggers that we 
use to manipulate Squeak-E computation would be written in Squeak, not 
Squeak-E, would be simple adaptations of the browsers and debuggers already 
written in Squeak, and can therefore use the conventional 
non-capability-oriented meta-level power already accessible to them in Squeak.

For example, by taming (eg, by Andreas' renaming) Squeak-E code would 
not be able to send the real #instVarAt: message to any objects. However, 
Squeak code can, and the existing inspectors do. Let's say further that, to 
Squeak code, Squeak-E objects seem to be normal Squeak objects. (Perhaps 
they are, but we can postpone that.) Let's say that all Squeak-E objects 
make their instance variables available to Squeak, but not to themselves or 
each other, through #instVarAt:. Then the normal Squeak-written inspectors 
can be used to inspect Squeak-E objects without much further work. (The 
further work is that doit/printit/inspectit in an inspector on a Squeak-E 
object should probably evaluate the selection by default as a Squeak-E 
expression rather than a Squeak expression.)

* As Dean says, the user already own the image he's running, so if these 
meta-level Squeak-written tools are in fact trustworthy -- are in fact 
acting in accord with the user's intentions -- then it violates no actually 
security for these tools to be able to violate the encapsulation of the 
objects within the user's image. You'd be losing only the ability to run 
meta-level tools you don't fully trust, a basis for remote debugging in 
images you don't control

I often run E under a Java debugger, which is logically exactly analogous, 
but much less pleasant. We are also making slow progress on an E-to-JVM 
bytecode compiler that would let us apply Java debuggers to E computation in 
a more pleasant fashion that would actually be analogous.

I also have various debugging tools written in Java for helping to debug E 
code. These are effectively part of the E implementation. Likewise, from 
Squeak-E's point of view, all tools written in Squeak that can be applied to 
Squeak-E are effectively part of the Squeak-E implementation.

* This direction would let the Squeak-E language shoot for 
level-4-with-no-meta-levels first, which is where E is currently at, before 
taking on something like the virtualization layers notion. And unlike E, 
Squeak-E could do this without sacrificing the Smalltalk-quality tool 
support, by just using (and slightly adapting) the existing tools. 

* While doing this, we should all continue discussing these fancier 
virtualization notions. I'd like to eventually move E in that direction as 

Do these points sound at all plausible? Does the twist sound like a good way 
to proceed?

Text by me above is hereby placed in the public domain


More information about the Squeak-e mailing list