Mark, you seem to be saying that we wouldn't have to change the vm, in 
order to 'host' a capability language, and write an E-interpreter.  
While that would be very interesting, my intension has been to 
transform squeak itself into a capability language.   This would 
require some VM changes, to create opaque references, and MOP changes, 
to handle the fact that Inspectors won't be able to look inside an 
object.

My motivation in suggesting separate segments (vats), was that squeak 
should be able to host concurrent users.  A vat, to my way of thinking, 
was an authenticated space, in addition to having the concurrency and 
persistent properties.  A user with certain amount of authority could 
create a vat, and be able to run with other vats in one image.   Squeak 
would then have a running system mode segment that could issue machine 
resource capabilities to the hosted users.   If a vat is attached to a 
process and is this unit of persistence and concurrency, then it is 
also the unit of exception handling and authentication.  I may be 
confusing TCB level security (secure communications platform - Trusted 
Computer Base), with user authentication and security.

If we look at every reference as a capability, then taming squeak will 
first involve taming each reference.   If my implementation of your 
eventual sending mechanism is to have any chance of becoming a more 
broadly used feature, even if the implementation changes, then it looks 
like there are really two library issues.  First, get the rest of the 
squeak  library to handle asynchronous objects, and second, to make 
sure the library is tamed for capabilities.

How should debugging in a secure environment proceed?   Certainly I 
don't want you looking inside of my objects, unless I give you that 
capability.   I would want to look inside of my objects and since I own 
them, I should have acquired the MOP capability to look inside them.

I am rereading the ode 
(http://www.erights.org/elib/capability/ode/index.html).

Regards,
rob

On Sunday, January 26, 2003, at 02:20 AM, Mark S. Miller wrote:

> What we did do is build a new language and virtual machine (Kernel-E) 
> on top
> of Java. For this, Java's similarity to a capability system was 
> irrelevant.
> For example, we have made a start on rebuilding the Kernel-E virtual 
> machine
> in C++ and it has the same structure. Needless to say, Smalltalk would 
> be
> fine here. I see no further relevant differences at the virtual 
> machine level.