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 self-malleability.)
* 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 well.
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
Cheers, --MarkM