SchemeLanguage
Erlang
Scala
ConcurrentProgramming
ObjectOrientedProgramming
in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received
- http://c2.com/cgi/wiki?ActorsModel
- Actors are autonomous and concurrent objects which execute asynchronously. The actors model provides flexible mechanisms for building parallel and distributed software systems.
- http://www.erights.org/history/actors.html
- research done by Hewitt's Message Passing Semantics group at MIT
- http://funcall.blogspot.com/2008/03/actor-model.html
- Sussman and Steele developed Scheme to explore some of the semantics of Hewitt's Actor model.
- They discovered that the code that implemented message passing and the code that implemented function application was identical (modulo the naming). In other words, a closure can be considered an actor that waits for a message (the arguments) and runs until it computes a value. Message passing is simply invoking a closure on a set of arguments. (This doesn't capture the entire Actor model, but it captures some interesting facets.)
- the need for TailCallOptimization for long delegation chains (one actor invoking another)
Clojure
There are other ways to model identity and state, one of the more popular of which is the message-passing actor model, best exemplified by the quite impressive Erlang. In an actor model, state is encapsulated in an actor (identity) and can only be affected/seen via the passing of messages (values). In an asynchronous system like Erlang's, reading some aspect of an actor's state requires sending a request message, waiting for a response, and the actor sending a response. It is important to understand that the actor model was designed to address the problems of distributed programs. And the problems of distributed programs are much harder - there are multiple worlds (address spaces), direct observation is not possible, interaction occurs over possibly unreliable channels, etc. The actor model supports transparent distribution. If you write all of your code this way, you are not bound to the actual location of the other actors, allowing a system to be spread over multiple processes/machines without changing the code.
- Erlang's actors are light-weight "user-land" processes (e.g. - "green threads") that are autonomous and can scale tremendously. Clojure's agents are native threads that are managed in thread pools for performance.
- In an asynchronous system like Erlang's, reading some aspect of an actor's state requires sending a request message, waiting for a response, and the actor sending a response. It is important to understand that the actor model was designed to address the problems of distributed programs.