[e-lang] Re: Comments on Lex's "Object as Capabilities in Squeak"

Mark S. Miller markm at caplet.com
Thu Jan 30 19:36:43 UTC 2003


At 11:27 PM 1/29/2003 Wednesday, Robert Withers wrote:

>Mark, I would like to thank you for this significant commitment you  
>have made in engaging us with your ideas.

Hey, no commitment! Just a strong desire. I'll do what I can. ;) ;)


>My goals have been to learn some of E's infrastructure, and to start  
>building towards multi-user squeak and mobile-code.   It looks like  
>this fits at your second level of ambition.  It would not surprise me  
>if this is the level Croquet is reaching for.
>
>However, I like the challenge and reward of your fourth level of  
>ambition.  It requires several orders of magnitude greater of a  
>community commitment.

Perhaps, but I don't think so. I think the tradeoff is instead how similar 
SafeSqueak is to Squeak, and how much Squeak is ported to SafeSqueak rather 
than tamed or rewritten. I think what is simply unachievable, no matter what 
level of community involvement, is to achieve the forth level with a 
language that is only painlessly different than existing Squeak.

As for effort, I think the tradeoff is the other way around. 

"Simplicity is the unavoidable price which we must pay for reliability." 
                       -- Tony Hoare.

Doubly so for security. Given a change of basic architectural principles, it 
is often easier to start over than it is to retrofit. Again, doubly so for 
security. E was born at Electric Communities under the same "The E 
Extensions to Java" http://www.erights.org/history/original-e/ . (That E is 
now known as "Original-E".) Java, like Squeak and Scheme, was already close 
to being a perfect pure capability language. (This is, in all three cases, 
ignoring the libraries.) So we thought we could define E as a capability 
secure variant of Java that would be close enough to port much old Java code.

Three years and $10M later, I think we understood the problem well enough 
that we could succeed at it, but even after that investment it would have 
been a much harder effort than what we did do: take those insights and build 
a new language from scratch a) on top of Java, b) designed to seem familiar 
to Java programmers, and c) inheriting the Java libraries via a taming 
mechanism so that E would start with a large endowment of working libraries.

OTOH, Jonathan Rees, in a one-man thesis-sized project, turned Scheme into 
W7. W7 is as fully capability secure as is E (actually, E without auditors), 
and is a minor an almost perfectly upwards compatible variant of Scheme. So 
it can go either way.

I can't say for certain which of these two cases is the better analogy to 
the task we face with Squeak, but I sadly suspect it's much more like the Java 
situation.




>  If I understand correctly, with the benefit of  
>having read on your site about financial capabilities, privileged  
>security abstractions allows for trusted "arbitrage" objects (my  
>terminology), which people could *really* trust.

"trust" is tricky. I think this statement is too strong in any case.

>As you ask in your mail, what would we lose from Squeak, or be willing  
>to lose, to do these things?

Good questions. More later... Probably not till Monday.


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

        Cheers,
        --MarkM



More information about the Squeak-dev mailing list