> Most of the Hewitt Actor papers are really worth reading -- as are 
> the preceeding PLANNER papers (from which I adapted many ideas for 
> Smalltalk-71, which we never got around to implementing). I agree 
> very much with Ken Kahn (and have agreed with him for many years), 
> that what we need is a more intentional and strategic form of 
> programming.
>       Carl Hewitt has never gotten the credit he deserved for being a 
> pioneer in this form of programming (with PLANNER). If you combine 
> this style with objects -- If you really make object-methods goal 
> satisfiers, etc., 

Found on: http://www-osl.cs.uiuc.edu

In the Actor model of Computation [Hewitt'77, Agha'85]: 
-  An actor is a reactive entity. 
-  In response to a message, an actor can: 
            - Create a new actor, 
            - Send a message to an acquaintance actor, or 
            - Change its internal behaviour. 

Asynchronous Buffered Messages 
-  Actors have unique mail addresses. 
-  Messages (potential method invocations) are buffered in a mailbox. 
-  Actors communicate only via asynchronous message passing. 
-  In the actor model, there is guaranteed message delivery. 

Synchronizers 
-  Synchronizers are linguistic constructs used to coordinate actor
interactions [Frolund'96].
<Put constr.gif here>

Casts 
-  A cast is a group of actors that encapsulates synchronization for those
actors. 
-  An actor can not belong to more than one cast. 
-  A cast of actors may have one or more directors. 

Is this what you were looking for?

(Rebecca Wirfs-Brock: "It is the function of the domain expert to provide
the team with accurate input about the details, and particularly to abstract
out which details are the relevant ones."
Not just sending messages but creating contracts between objects is the core
of her CRC-technics. The problem is the gap between using crc-crads for the
first design-draft and the details that pop-up during the next steps: how to
communicate these back to the domain-expert, so he can choose again? ) 
> then you get into a much better place for 
> programming in general. This was what ST-71 was all about. We always 
> encourage Smalltalkers to program as if they are satisfying goals 
> with methods, but this is kind of weak tea without extensive language 
> support.
>       Ken has done a number of languages over the years that have 
> shown many interesting insights about this way to program. One of 
> them was a language called VULCAN -- and there are several good 
> papers that he wrote about these languages (maybe we can get him to 
> give us URLs if they are online).
> 
> >
> >>Recently Andreas Raab has done some remarkable experiments with 
> >>very large numbers of very low overhead processes in Squeak which 
> >>bodes well for the future.
> >
> >I am still not quite sure for what specific problems large numbers 
> >of processes are a good solution.  Computing propagation patterns 
> >on-the-fly and interleaved with the computation carried out by the 
> >message payload may be one case, but many/most practical cases seem 
> >to be solvable without the need for concurrency.
> 
> It's not so much about concurrency as about environments. And it's 
> not so much about solution as realization.
> 
> Cheers,
> 
> Alan
> -- 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: constr.gif
Type: image/gif
Size: 7800 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20011013/d05197df/constr.gif