[Squeak-e] Re: [e-lang] Re: Croquet, Unum questions

[Brian T. Rice]

Hello,

I am a long-time Squeaker, and have been following E and Squeak-E 
discussions and issues with interest. I am implementing what I consider 
to be a successor system to Squeak, titled "Slate" (see 
http://slate.tunes.org) which has been designed at least with expansion 
in mind to handle the issues that E does. I am currently working on the 
new concurrency mechanisms, and would like to know some details on your 
thoughts at this point for Squeak-like languages (after the debate over 
a year ago concerning the issues, which I did follow, I'm concerned with 
new developments).

Slate has essentially "zero baggage", and deals with a few issues 
mentioned previously about making Squeak capability secure (methods 
don't return "self" by default, and namespaces are well-structured and 
logical). I can elaborate in detail if necessary, but there is also a 
manual on our website which should give a good overview.

The virtual machine architecture is less well-documented being a newer 
development and just now reaching a stable design, but again it has very 
little baggage and no legacy overhead, so it is ripe for considering new 
ideas.

As a Squeak user, Croquet's project structure is relatively opaque, but 
of course the ideas are still interesting and lie within the field of 
projects that I want Slate to provide a better base for than Squeak 
currently does.

I don't have specific questions to start with, other than requesting 
some detailed overviews of how a Smalltalk-like architecture could be 
adapted to support E-like concurrency from the ground up (forgetting how 
any Smalltalk currently does it), and to start a discussion about 
specifics concerning Slate.

Thank you,
Brian Rice

Mark Miller wrote:
> On 2004, Jul 24, , at 19:05, Mark Miller wrote:
> 
>>[...] Several of us were distracted, in a major way, this
>>week. More about that soon...
> 
> We were distracted by an invitation-only workshop, held at HP Labs, focused 
> on exploring future possibilities for Croquet. 
> http://chess.eecs.berkeley.edu/croquet/ is a start on a website resulting 
> from this workshop. The workshop was organized by Rick McGeer and attended 
> by about 30 people, including 
> * three of the main Croquet architects (David Smith, David Reed, and Andreas Raab), 
> * several other Croquet-ers (Mark McCahill, Julian Lombardi) 
> * and Squeakers (Dan Ingalls, Ted Keahler, Lex Spoon, Anthony Hannan, Ian Piumarta, Scott Wallace), 
> * several members of the e-lang community (Chip Morningstar, Kevin Reid, Ka-Ping Yee, Marc Stiegler, Alan Karp, Tyler Close, Dean Tribble, and myself), 
> * George Bosworth of Digitalk Smalltalk and .NET CLR fame, 
> * Robert Adams of Intel and PlanetLab,
> * and Prof. Edward Lee of Berkeley.
> * (and probably some others I forgot)
> 
> 
> The Electric Communities and e-lang perspectives were represented well, and 
> played well with other perspectives that were presented. I think the 
> lessons from our perspectives were taken to heart, and their relevance to 
> the Croquet undertaking were clear. Actually, I think I'm way understating 
> the case, but I'll wait to see what others have to say.
> 
> In any case, I think it's fair to say that we have consensus on using 
> object-capability security as the underlying security mechanism, on top of 
> which Croquet's security architecture should be built. And that we have 
> consensus that "Threads are evil" -- that the conventional (shared memory 
> multithreading & fine-grained locking) paradigm of concurrency is
> unworkable, and that instead, time should proceed according to a partial 
> causal order among events, where each event is the deterministic execution 
> of a sequential program to completion. (E and Croquet already have this 
> perspective in common, but with some interesting differences.)
> 
> I have asked the Croquet architects to evaluate the suitability of the 
> Kernel-E virtual machine definition as a proposed foundation on which 
> Croquet should be reconstructed. They are currently evaluating it. If 
> adopted, the plan would probably be to start by completing Dean's 
> E-on-Squeak effort in the short term, and do a more direct implementation of 
> Kernel-E on their virtual machine infrastructure in the long term. 

> At 04:05 PM 7/28/2004  Wednesday, Kevin Reid wrote:
> 
>>>(Note: the picture painted here doesn't yet cover the case where there are
>>>potentially multiple authoritative presences. I now think I like Dean's
>>>proposal for that better than Uni-Tea
>>>http://www.erights.org/talks/uni-tea/index.html .
>>
>>I don't recall or never heard what Dean's proposal was.
> 
> In the Uni-Tea proposal, we map a Tea Party to an Unum, and make the 
> replication of authoritative presences be a generalization of presence 
> spread among vats. Dean suggests that, instead, we map a Tea Party to a 
> virtual vat, and implement fault tolerant replicated vats. Then, at the vat 
> level of abstraction, an individual Unum would still just have one 
> authoritative presence, permanently tied to its virtual vat of origin. 
> Rather than making the replication, consensus, and fault tolerance protocols 
> be Unum design choices, we should make these choices when instantiating a 
> fault-tolerant replicated vat. In Dean's proposal, it is especially clear 
> that you only do fault tolerant replication among sites mutually trusted to 
> try to run their replicas correctly, since that vat's private key would be 
> replicated at all those sites.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: water.vcf
Type: text/x-vcard
Size: 208 bytes
Desc: not available
Url : /archives/slate/attachments/20040823/5deecabf/water.vcf