It's Actors All The Way Down

The Actor Model of computation does not define a programming language. It defines a semantic model. This post attempts to describe the minimal features required in any programming language that implements the Actor Model.

Actor Primitives

A programming language for actors must begin with support for the three primitive actor operations:

• Create a new actor
• Send a message to an existing actor
• Designate a new behavior for the current actor

Create an Actor

Each newly created actor has a unique address, distinct from all other actors, to which messages may be sent. Initially, this address in known only to the newly created actor and the actor that created it.

In order to create a new actor, its initial behavior must be specified. The behavior describes how the actor will respond to messages. Multiple actors may have the same behavior, but will remain distinct independent actors (designated by their addresses).

So, an actor language requires some way to represent an actor’s address, and some way to describe an actor’s behavior. Also, actors need some way to refer to themselves, so they can share their address with other actors.

Send a Message

In order to send a message to an actor, its address must be known. Messages must be able to communicate, at least, actor addresses. Messages are sent asynchronously. The sender does not wait for the message to be delivered, let alone acted upon.

Messages may contain the addresses of actors to whom responses may be directed, but there is no “return value” from a message send. Each message send is a distinct event, even if the target actor and message contents are identical.

So, an actor language requires some way to compose a message (which may include actor addresses), and some way to send a message to an actor designated by its address.

Change Behavior

State and behavior are duals. The only way to observe the “state” of an actor, is to observe how it behaves when it receives a message. This can only be done if the actor sends a message in response.

Part of the behavior of an actor may be the designation of a new behavior for subsequent messages. This is how an actor changes state, by updating its behavior. We say that an actor becomes a new behavior. Of course, a new behavior designation is not required. The actor may choose to process additional messages with its current behavior.

So, an actor language requires a way to optionally designate a new behavior for the current actor in response to receiving a message.

Fundamental Data Types

The semantics of the actor primitives implies the existence of several fundamental data types:

• Address
• Behavior
• Message

Note that these are all immutable data types. The only type of mutation required by an actor language is behavior replacement (become) for actors in response to a message.

Address

Actors are identified by their address. An actor’s address represents the capability to send messages to the actor. There is no way to invoke an actor’s behavior other than sending it a message.

An actor’s address may become know only by one of these means:

• Initial conditions. An actor always knows its own address. Also, a configuration may be defined to have pre-existing addresses available (this may introduce security hazards).
• Parenthood. An actor is given the address of each actor it creates.
• Endowment. An actor may be created with addresses of actors known by its creator.
• Introduction. An actor may send and receive actor addresses in messages. This is how the address reference graph grows.

It is important to note that there is no way to synthesize an actor address from bits of data. When actor addresses must be transported over a bit-stream, it is the responsibility of the communication system to convert local actor addresses to and from external network representations.

An actor language needs some way to send a message to an actor whose address is known, and some way to determine that two addresses (while remaining opaque) are the same.

Behavior

The behavior of an actor describes the actions it will take when it receives a message. These actions may include creating one or more additional actors, sending one or more messages, and designating a new behavior for the current actor. In other words, a collection of primitive actor operations.

To the extent that an actor may be described as having a “state”, that state is encoded in the actor’s behavior. The actor’s state is private. It can only be revealed if the actor chooses to send it in a message. Behavior replacement (become) implements actor state change.

An actor language needs some way to describe the collection of actions an actor will take in response to a message. Some of the data in the message may be used to determine the response. This implies some sort of decision-making or conditional processing based on message contents.

Message

A message is an immutable value used to pass data between actors. Messages may include actor addresses (which are, of course, immutable). A message may even be empty. Arrival at the target is still a signal of significance. Behaviors may, or may not, be communicable, depending on the language.

An actor language needs some way to compose a message consisting of immutable data (including actor addresses), and some way to recognize and decompose a message on reception.

Summary

Any actor language must support the three primitive actor actions:

• Create
• Send
• Become

In order to support these primitive actions, an actor language must support at least three types of values:

• Address
• Behavior
• Message

Additional language mechanisms, such as rich data types, expression evaluation, variable binding or assignment, conditional flow, pattern matching, etc. may be provided by particular actor languages, but are not required to be considered an “actor language”. Specific sets of design decisions will be explored in subsequent posts.