Lambda the Ultimate

[Karmani and Agha 2011] promoted the Fog Cutter [so named by Kristen Nygaard] model in which each computational agent is defined to have a mailbox, thread, state, and program. However, the Fog Cutter is not a general model of Actors because of the following differences:
• Each computational agent has a ‘mailbox’. But if everything that interacts is an Actor, then a mailbox must be an Actor and so in turn needs a mailbox which in turn…[ Hewitt, Bishop, and Steiger 1973] Of course, mailboxes having mailboxes is an infinite regress that has been humorously characterized by Erik Meijer as “down the rabbit hole.” [Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)]
• A computational agent ‘terminates’ when every computational agent that it has created is ‘idle’ and there is no way to send it a message. In practice, it is preferable to use garbage collection for Actors that are inaccessible. [Baker and Hewitt 1977]
• Each computational agent executes a ‘loop’ using its own sequential ‘thread’ that begins with receiving a message followed by possibly creating more computational agents, sending messages, updating its local state, and then looping back for the next message. In practice, it is preferable to provide “Swiss cheese” by which an Actor can concurrently process multiple messages without the limitation of a sequential thread loop.
• A computational agent has a well-defined local ‘autonomous’ ‘state’ that can be updated while processing a message. However, because of indeterminacy an Actor may not be in a well-defined local independent state. For example, Actors might be entangled with each other so that their actions are correlated. Also, large distributed Actors (e.g. www.dod.gov) do not have a well-defined state. In practice, it is preferable for an Actor not to change its local information while it is processing a message and instead specify to the information to be used in how it will process the next message received.

The Fog Cutter model has been extremely useful for exploring issues about Actors including the following alternatives:
• Reception order of messaging instead of mailbox
• Activation order of messaging instead of thread
• Behavior instead of state+program

In practice, the most common and effective way to explain Actors has been operationally using a suitable Actor program language (e.g., ActorScript) that specifies how Actors can be implemented along with an English explanation of the axioms for Actors.

For more information see Actor Model of Computation