Actor Script TM

Published in ArXiv http://arxiv.org/abs/0907.3330 http://ActorScript.carlhewitt.
info
ActorScript™:
Industrial strength integration of local and nonlocal concurrency
for Client-cloud Computing
Carl Hewitt
http://carlhewitt.info
This paper is dedicated to Seymour Papert.
ActorScript™ is a general purpose programming language for implementing massive local and nonlocal
concurrency. It is differentiated from other concurrent languages by the following:
 Identifiers (names) in the language are referentially transparent, i.e., in a given scope an identifier
always refers to the same thing.
 Everything in the language is accomplished using message passing including the very definition of
ActorScript itself.
 Binary XML and JSON are fundamental, being used for structuring both data and messages.
 Functional and Logic Programming are integrated into general concurrent programming.
 Advanced features such as eventing, co-routines, futures, serializers, sponsors, etc. can be defined and
implemented without having to resort to low level implementation mechanisms such as threads, tasks,
channels, queues, locks, cores, etc.
 For ease of reading, programming can be displayed using a 2-dimensional textual typography (as is
often done in mathematics).
 ActorScript attempts to achieve the highest level of performance, scalability, and expressiblity with a
minimum of primitives.
Contents An implementation of Futures .................................. 19

Sponsors .................................................................... 23
Actor Model ..................................................................... 2 Logic Programming .................................................. 27
Fundamental concepts ................................................. 2 Acknowledgment .......................................................... 28
Illustrations .................................................................. 2 Bibliography .................................................................. 28
Direct communication and asynchrony ....................... 2 Appendix: Historical Background ................................ 32
Locality and Security ................................................... 3 Petri nets .................................................................... 32
Computational Representation Theorem..................... 3 Simula ....................................................................... 32
Comparison with other models of message-passing Planner....................................................................... 32
concurrency.................................................................. 4 Smalltalk-72 .............................................................. 32
ORGs ........................................................................... 4 Actors ........................................................................ 33
Privacy-friendly, client cloud computing.................... 4 Actor Semantics ........................................................ 33
ActorScript ....................................................................... 5 Logic Programming .................................................. 34
Meta-circular Eval procedure in Lisp ......................... 5 Reasoning about Actors ............................................ 35
Eval as a Message ........................................................ 6 Early Actor Programming languages ....................... 35
Interfaces...................................................................... 6 Hairy Control Structure Redux ................................. 35
Procedure invocations ................................................. 7 Promises .................................................................... 36
Control expressions ..................................................... 8 Garbage Collection ................................................... 36
Structural Expressions ................................................. 8 Cosmic Cube ............................................................. 36
Compound Expressions ............................................... 8 J–Machine ................................................................. 36
Parallelism Expressions ............................................... 9 Pi-calculus ................................................................. 37
Eventing ..................................................................... 10 Was the Actor model premature? ............................. 37
Co-routining............................................................... 11 End Notes ...................................................................... 38
Customers .................................................................. 11
Exceptions.................................................................. 12
Concurrent Programming .......................................... 12
Serializing .................................................................. 14
December 14, 2009 Page 1 of 42

Actor Modeli creation of Actors, inclusion of Actor addresses in
messages, and interaction only through direct
ActorScript is based on a mathematical model of asynchronous message passing with no restriction on
computation that treats “Actors” as the universal primitives message arrival order.
of concurrent digital computation [Hewitt, Bishop, and
Steiger 1973; Hewitt 1977]. Actors been used both as a
Illustrations
framework for a theoretical understanding of concurrency,
and as the theoretical basis for several practical The Actor model can be used as a framework for
implementations of concurrent systems. modeling, understanding, and reasoning about, a wide
range of concurrent systems. For example:
Unlike previous models of computation, the Actor model  Electronic mail (e-mail) can be modeled as an
was inspired by physical laws. It was also influenced by Actor system. Accounts are modeled as Actors
the programming languages Lisp [McCarthy et. al. 1962], and email addresses as Actor addresses.
Simula [Dahl and Nygaard 1967] and Smalltalk-72 [Kay  Web Services can be modeled with SOAP
1975], as well as ideas for Petri Nets [Petri 1962], endpoints modeled as Actor addresses.
capability-based systems [Dennis and van Horn 1966] and  Objects with locks (e.g. as in Java and C#) can be
packet switching [Baran 1964]. Its development was modeled as serializers (see below), provided that
“motivated by the prospect of highly parallel computing their implementations are such that messages can
machines consisting of dozens, hundreds or even thousands continually arrive.
of independent microprocessors, each with its own local
memory and communications processor, communicating Direct communication and asynchrony
via a high-performance communications network.” Messages in the Actor model are decoupled from the
[Clinger 1981] Since that time, the advent of massive sender and are delivered by the system on a best efforts
concurrency through client-cloud computing and many- basis. This was a sharp break with previous approaches to
core computer architectures has rekindled interest in the models of concurrent computation in which message
Actor model [Hewitt 2009b]. sending is tightly coupled with the sender and sending a
message synchronously transfers it someplace, e.g., to a
Fundamental concepts buffer or to the “ether” or “environment” where it
An Actor is a computational entity that, in response to a temporarily resides. The lack of synchronicity caused a
message it receives, can concurrently: great deal of misunderstanding at the time of the
 send a finite number of messages to other Actors; development of the Actor model and is still a controversial
 create a finite number of new Actors; issue.
 designate the behavior to be used for the next
message it receives. Because message passing is taken as fundamental in the
Actor model, there cannot be any inherent overhead, e.g.,
any requirement for buffers, channels, etc... Prior to the
There is no assumed sequence to the above actions and Actor model, concurrency was defined in low level
they could be carried out concurrently. machine terms of threads, locks, channels, queues, cores,
etc. It certainly is the case that implementations of the
Decoupling the sender from communications sent was a Actor model typically make use of these hardware
fundamental advance of the Actor model enabling capabilities. However, there is no reason that the model
asynchronous communication and control structures as could not be implemented directly in hardware without
patterns of passing messages [Hewitt 1977]. exposing any hardware threads, locks, queues, channels,
tasks, etc. Also, there is no necessary relationship between
An Actor can only communicate with Actors to which it is the number of Actors and the number threads, locks, tasks,
connected. It can directly obtain information only from queues, etc. that might be in use. Implementations of the
other Actors to which it is directly connected. Connections Actor model are free to make use of threads, locks, tasks,
can be implemented in a variety of ways: queues, global assignment, coherent memory, transactional
 direct physical attachment memory, cores, etc. in any way that is compatible with the
 memory or disk addresses laws for Actors.
 network addresses
 email addresses As opposed to the previous approach based on composing
sequential processes, the Actor model was developed as an
inherently concurrent model. In the Actor model sequential
The Actor model is characterized by inherent concurrency
of computation within and among Actors, dynamic

ordering is a special case that derived from concurrent  tagged memory as in Lisp machines, etc.
computation.  virtual machines as in Java virtual machine,
Common Language Runtime, etc.
A natural development of the Actor model was to allow  signing and/or encryption of Actors and their
Actor addresses in messages. A computation might need to addresses
send a message to a recipient from which it would later
receive a response. The way to do this is to send a A delicate point in the Actor model is the ability to
communication which has the message along with the synthesize the address of an Actor. In some cases security
address of another Actor called the customer along with can be used to prevent the synthesis of addresses.
the message. The recipient could then cause a response However, if an Actor address is simply a bit string then
message to be sent to the customer. clearly it can be synthesized given eons of time although it
can be made unguessable in practice if the bit strings are
Of course, any Actor could be used as a customer to long enough.
receive a response message. By using customers, common
control structures such a recursion, co-routines, Computational Representation Theorem
hierarchical parallelism, futures [Baker and Hewitt 1977],
etc. can be implemented. There is a Computational Representation Theorem in the
Actor model for systems which are closed in the sense that
they do not receive communications from outside. A
Messages in the Actor model are analogous to packets in closed system is defined to be one which does not
Internet computing in that they need not be received in the communicate with the outside. Actor model theory
order sent. Not providing the order of delivery guarantee provides the means to characterize all the possible
allows packet switching to buffer packets, use multiple computations of a closed system in terms of the
paths to send packets, resend damaged packets, and to Computational Representation Theorem [Clinger 1981;
provide other optimizations. Hewitt 2006]:
The denotation DenoteS of a closed system S represents
⊔
For example, Actors are allowed to pipeline the processing all the possible behaviors of S as
of messages. What this means is that in the course of DenoteS = i
iω ProgressionS (⊥S)
processing a message m1, an Actor can designate the
behavior to be used to process the next message, and then where ProgressionS is an approximation function that
in fact begin processing another message m2 before it has takes a set of partial behaviors to their next stage and
finished processing m1. Just because an Actor is allowed ⊥S is the initial behavior of S.
to pipeline the processing of messages does not mean that
it must pipeline the processing. Whether a message is In this way, the behavior of S can be mathematically
pipelined is an engineering tradeoff. characterized in terms of all its possible behaviors
(including those involving unbounded nondeterminism).
Locality and Security
Although DenoteS is not an implementation of S, it can be
Another important characteristic of the Actor model is
used to prove a generalization of the Church-Turing-
locality. Locality means that in processing a message: an
Rosser-Kleene thesis [Kleene 1943]:
Actor can send messages only to addresses for which it has
information by the following means: Enumeration Theorem: If the primitive Actors of a
1. that it receives in the message closed Actor System S are effective, then the possible
2. that it already had before it received the message outputs of S are recursively enumerable.
3. that it creates while processing the message. Proof: Follows immediately from the
Representation Theorem.
In the Actor model, there is no simultaneous change in
multiple locations. In this way it differs from some other The upshot is that concurrent systems can be
models of concurrency, e.g., the Petri net model in which represented and characterized by logical deduction
tokens are simultaneously removed from multiple locations but cannot be implemented. Thus, the following
and placed in other locations. practical problem arose:
How can practical programming languages be
The security of Actors can be protected in the following rigorously defined since the proposal by Scott and
ways: Strachey [1971] to define them in terms lambda
 hardwiring in which Actors are physically calculus failed because the lambda calculus cannot
connected implement concurrency?

To address the above, ORGs (Organizations of Restricted
One solution is to develop a concurrent variant of the Lisp Generality™) have been developed as a paradigm in which
meta-circular definition [McCarthy, Abrahams, Edwards, organizations have people that are tightly integrated with
Hart, and Levin 1962] that was inspired by Turing's information technology that enables them to function
Universal Machine [Turing 1936]. If exp is a Lisp organizationally [Hewitt and Inman 1991; Hewitt 2008a,
expression and env is an environment that assigns values 2008b, 2008d, 2008e].iii ORGs formalize existing practices
to identifiers, then the procedure Eval with arguments exp to provide a framework for addressing issues of authority,
and env evaluates exp using env. In the concurrent accountability, scalability, and robustness using methods
variant, Eval<env> is a message that can be sent to exp to that are analogous to human organizations.iv
cause exp to be evaluated. Using such messages, modular
meta-circular definitions can be concisely expressed in the ORGs are structured around organizational commitment
Actor model for universal concurrent programming defined as information pledged [Hewitt 2007]. For
languages (e.g. see ActorScript below). example, ORGs can use contracts to formalize their mutual
commitments to fulfill specified obligations to each other.
Comparison with other models of message-passing Yet, manifestations of information pledged will often be
concurrency inconsistent. Any given contract might be internally
inconsistent, or two contracts in force at one time could
ActorScript does not have the following restrictions of contradict each other. Issues that arise from such
other models of message-passing concurrency:ii inconsistencies can be negotiated among ORGs.
 Single threadedness: ActorScript has no
restrictions on the use of threads in its ORGs can make use of the following information system
implementation. principles [Hewitt 2008g]:
 Message delivery order: ActorScript has no  Monotonicity: Once something is published it
restrictions on message delivery order. cannot be undone. Published work is collected and
 Lack of garbage collection (automatic storage indexed.
reclamation): ActorScript is designed for use in  Concurrency: Works proceeds interactively and
the following systems: concurrently, overlapping in time.
 CLR and extensions (Microsoft)  Commutativity: Publications can be read regardless
 JVM (Sun, IBM, Oracle, SAP) of whether they initiate new work or become
 LLVM (Apple) relevant to ongoing work.
 Dalvik (Google)  Sponsorship: Sponsors provide resources for
In due course, we will need to extend the above computation, i.e., processing, storage, and
systems with a tagged extension of the X86 communications. Publication and subscription
architecture. Many-core architecture has made a require sponsorship although sometimes costs can
tagged extension necessary in order to provide the be offset by advertising.
following:  Pluralism: Publications include heterogeneous,
 concurrent, nonstop, no-pause automatic overlapping and possibly conflicting information.
storage reclamation (garbage collection) and There is no central arbiter of truth
relocation to improve efficiency,  Skepticism: Great effort is expended to test and
 prevention of memory corruption that otherwise validate current information and replace it with
results from programming languages like C and better information.
C++ using thousands of threads in a process,  Provenance: The provenance of information is
 nonstop migration of ORGs (while they are in carefully tracked and recorded.
operation) within a computer and between
distributed computers
Privacy-friendly, client cloud computing
Imposing restrictions on threadedness, message order In Client Cloud Computing, information is permanently
arrival, and garbage collection (automatic storage stored in servers on the Internet and cached temporarily on
management) can greatly diminish the performance and clients that range from single chip sensors, handhelds,
scalability of Actor systems. notebooks, desktops, and entertainment centers to huge
data centers. (Even data centers often cache their
ORGs information to guard against geographical disaster.) Client
cloud computing will provide new capabilities including
In the organization lies the power. the following:
 maintaining the privacy of client information by
storing it on servers encrypted so that it can be

decrypted only by using the client‟s private key. Meta-circular Eval procedure in Lisp
(The information is unencrypted only when cached John McCarthy is justly famous for Lisp. One of the more
on a client.)v remarkable aspects of Lisp was the definition of its
 allowing greater integration of user information interpreter (called Eval) in Lisp itself. The exact meaning
obtained from the servers of competing vendors of Eval defined in terms of itself has been somewhat
without requiring them to interact with each other. mysterious since on the face of it, the definition is circular.
A consequence is the client becomes the
monetization platform providing better advertising The purpose of this article is to develop a way in which a
relevance and targeting without exposing client further development of McCarthy’s idea can be used to
privacy provide a denotational semantics for concurrent
programming.
This work has resulted in the following developments:
 Direct LogicTM [Hewitt 2008e] to more safely It might seem that a meta-circular definition is a strange
reason about pervasively inconsistent information way to define a programming language. However, as
 concurrent reasoning [Hewitt 2008e] for many- shown in the body of the paper, concurrent programming
core processors (e.g. Larrabee) that cannot be languages are not reducible to logic. Consequently, an
implemented using logical deduction. (Although augmented meta-circular definition may be one of the best
direct and Bayesian inference are used together alternatives available.
locally, they are inadequate to accomplish the
overall results of concurrent reasoning.) Consider a dialect of Lisp which has a simple conditional
expression of the form (If test then else) which returns the
value of then if test evaluates to true and otherwise
ActorScript returns the value of else. So the definition of Eval in terms
A program should not only work; it should of itself might include something like the following
also appear to work. [McCarthy, Abrahams, Edwards, Hart, and Levin 1962]:vi
ActorScript is a general purpose programming language (Eval expression environment) 

for implementing massive local and nonlocal concurrency. ; Eval of expression using environment is defined to be
(If (Numberp expression)
It is differentiated from other concurrent languages by the
; if expression is a number then
following: expression
 Identifiers (names) in the language are referentially ; return expression else
transparent, i.e., in a given scope an identifier always (If ((Equal (First expression) (Quote if))
refers to the same thing. ; if First of expression is (quote if) then
 Everything in the language is accomplished using (If (Eval (First (Rest expression) environment)
message passing including the very definition of ; if Eval of First of Rest of expression is true then
ActorScript itself. (Eval (First (Rest (Rest expression)) environment)
 Binary XML and JSON are fundamental, being used ; return Eval of First of Rest of Rest of expression else
(Eval (First (Rest (Rest (Rest expression)) environment))
for structuring both data and messages.
; return Eval of First of Rest of Rest of Rest of expression
 Functional and Logic Programming are integrated …))
into general concurrent programming.
 Advanced concurrency features such as futures [Bake The above definition of Eval is notable in that the
and Hewitt 1977], serializers, sponsors, etc. can be definition makes use of the conditional expressions using if
defined and implemented without having to resort to expressions in defining how to Eval an If expression!
low level implementation mechanisms such as
threads, tasks, locks, and cores. In the sections below the denotational semantics of Actors
 For ease of reading, programming can be displayed [Clinger 1981, Hewitt 2006] are used to define the
using a 2-dimensional textual typography (as is often semantics the Actor programming language ActorScript™.
done in mathematics). ActorScript is an Actor programming language in the sense
 ActorScript attempts to achieve the highest level of that it directly expresses important aspects of the behavior
performance, scalability, and expressiblity with a of Actors.
minimum of primitives.
A challenging part of the definition of ActorScript in itself
is specifying that every message that is sent to an Actor
will arrive.

Eval as a Message
The following standard abbreviations will be used
The basic idea is to send an Eval message with an in the remainder:
environment to an expression instead of the Lisp approach
of calling an Eval procedure with the expression and
 ? for the universal type (interface)
environment as arguments.  Eval  Evaluate
 Env  Environment
Each Eval message has an environment with the bindings  Exp  Expression
of program identifies. Environment Actors are immutable,  Cust  Customer
i.e., they do not change.  Com  Communication
A “package” notation is used for XML in ActorScript
programs. . For example, depending out how it is printed,vii Interfaces
PersonName<First<“Kurt”> Last<“Gödel”> > can be
equivalent to An Actor can implement an indefinite and dynamically
XML*<”PersonName”> number of interfacesxi where each interface can specify
XML*<”First”> “Kurt” </”First”>+ signatures of messages received and the value returned.xii
XML*<”Last”> “Gödel “</”Last”>+
</”PersonName”>+ interface methodDescriptions
and could print as:viii
<PersonName> A new interface can be defined with method descriptions.
<First> Kurt </First> Note: in practice, interfaces are typically bound to
<Last> Gödel </Last> identifiers using version and configuration control.
</PersonName>
XML Attributes are allowed so that the expression

CountryXML{“capital” = “Paris”}<“France”>
can be equivalent to Meta-circular programs are enclosed in dashed boxes. The
XML*<”Country” “capital”=“Paris”> example below is a definition of the Env interface that
“France” makes use of  to indicate the beginning of a
</”Country”>} comment that runs to the end of the line:
and could print as:
<Country capital=“Paris”>
France Env 
</Country>  Env(i.e. Environment) is defined to be
JSON is another primitive data type. Below is a typical interface
JSON expression:  an interface of with the following 2 methods
JSON{ 𝐢
"firstName": "John", 𝐁𝐢𝐧𝐝 < 𝐯𝐚𝐥𝐮𝐞 >
𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫
"lastName": "Smith", 𝐄𝐧𝐯
"address": JSON{
 a Bind message returns an Env
"streetAddress": "21 2nd Street",
"city": "New York", 𝐢
"state": "NY", 𝐋𝐨𝐨𝐤𝐮𝐩 < 𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫 >
"postalCode": 10021}, ?
ix
"phoneNumbers": JSON["555-1234", "555-4567"]}
In this paper, the dialect of ActorScript used is quite

Below is a meta-circular definition of the Actor EmptyEnv
primitive in order to make the language definition smaller
that implements the Env interface:
while still being readable and incorporating mechanisms
such as exceptions that are necessary for Software
Engineering.x


EmptyEnv 𝐄𝐧𝐯 Exp 
behavior  Exp(i.e. Expression) is defined to be
implements Env interface
𝐢
Lookup<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫>  an interface with the following methods
? 𝐞
 received a request to lookup the identifier i Eval< >
𝐄𝐧𝐯 ?
throw NotFound
 throw the exception NotFound
𝐞
Match<value >
𝐢 𝐄𝐧𝐯 𝐄𝐧𝐯
Bind<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫 value>  a Match message returns an Env
𝐄𝐧𝐯
 received a request to bind the
 identifier i to value
identifier
return CreateEnv(Binding, EmptyEnv)
Identifiers in ActorScript are referentially transparent in
the sense that there is no assignment command.
𝐟𝐢𝐫𝐬𝐭 𝐫𝐞𝐬𝐭 
𝐂𝐫𝐞𝐚𝐭𝐞𝐄𝐧𝐯 , 𝐄𝐧𝐯
𝐁𝐢𝐧𝐝𝐢𝐧𝐠 𝐄𝐧𝐯 identifier 
behavior behavior
implements Env implements Exp
𝐢 𝐞
Lookup< > Eval<𝐄𝐧𝐯> return eLookup<self>
? ?
let Binding<firstIdentifier firstValue> = first,
cases i 𝐞
Match<value >
firstIdentifier  return firstValue 𝐄𝐧𝐯 𝐄𝐧𝐯
not firstIdentifier  return restLookup return eBind<self value>
𝐢
Bind<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫 value>
𝐄𝐧𝐯
return CreateEnv(Binding, self )
Procedure invocations
procedure (expression1 …expressionn)

The semantics of ActorScript are defined by taking each
construct in an ActorScript program and defining it as an
Actor with its own behavior. Execution is modeled by Functional applications are a standard programming
having Eval messages passed among program constructs language construct that is equivalent to the following
during execution. (see explanation below):
procedure [expression1 …expressionn]
Functions are implemented as unserialized Actors. For

example, consider the illustration below.

Illustration: let pattern =value ,body
Below is the definition of Iteration(f, i), which is the ith let expressions are a standard programming
iteration of f, e.g., (iteration(f, 2))(x) is f(f(x)). language construct where there is just one case. It can
𝐟 𝐢  be considered to be equivalent to
Iteration( , ) [𝐈𝐧𝐭𝐞𝐠𝐞𝐫]
[𝐈𝐧𝐭𝐞𝐠𝐞𝐫] 𝐈𝐧𝐭𝐞𝐠𝐞𝐫
𝐈𝐧𝐭𝐞𝐠𝐞𝐫 𝐈𝐧𝐭𝐞𝐠𝐞𝐫 cases value
 f is a procedure that takes a single pattern return body
 integer argument and returns an integer
If pattern does not match value, then throw the
exception CaseNotFound< >..
[x]
𝐈𝐧𝐭𝐞𝐠𝐞𝐫
cases i Structural Expressions
0  return x [expression1 . . . expressionn]xiii
(> 0)  return (Iteration(f, i-1))(x)
A sequence of expressions is evaluated to produce a new
sequence with the respective values.
Control expressions Sequence construction can be performed in the following

cases expression ways:
 [ [1 2] [3 4]] evaluates the same as [ [1 2] 3 4]
pattern1 expression1
 [ [1 2] [3 4]] evaluates the same as [1 2 [3 4] ]
…  [ [1 2]  [3 4]  [5 6] ] evaluates the same as
patternn  expressionn [1 2 [3 4] 5 6]
 [ [1 2]  [3 4] ] evaluates the same as [1 2 3 4]
cases expressions are a standard programming  [ [1 2] ] evaluates the same as [1 2 ]
language construct:  [ [1 2] ] evaluates the same as [1 2 ]
If expression matches pattern1 then
evaluate expression1 etc. up to if expression Compound Expressions
matches patternn then evaluate
expressionn ; otherwise throw the exception {discard ; value }
CaseNotFound< >. The expressions discard and value are evaluated
sequentially, i.e., evaluation of value does not
begin before discard has responded with one of
the following:
1. A return value that is discarded and then
value is evaluated to produce the response
(if any) for {discard ; value }..
2. An exception that is rethrown to produce
the response for {discard ; value } and
the evaluation of value is never begun.

{discard , value } Illustration:
The procedure Accumulate in parallel adds up all the
Evaluation of expressions discard, and value numbers of the subsequence between two indices in
can be interleaved.. i.e. there are no restrictions on sequence.
how discard and value are evaluated except 𝐬𝐞𝐪 𝐟𝐫𝐨𝐦, 𝐭𝐨 
Accumulate( )
that: 𝐍𝐮𝐦𝐛𝐞𝐫 ∗ 𝐍𝐮𝐦𝐛𝐞𝐫 𝐍𝐮𝐦𝐛𝐞𝐫
1. A return value of discard is discarded  seq is a sequence of numbers
and the response (if any) of value passed cases to-from  the cases for to-from are
back for {discard , value }. 0  return 0
 return 0 because the subsequence is empty
2. If the evaluation of discard or value 1  return seq[from]
generates an exception then any such  return the only element of the subsequence
exception can be rethrown for  note that indexing notation is allowed for sequences
{discard , value }.
3. If there is no response from evaluating 2  return seq[from]+ seq[from+1]
discard or value , then evaluation of  return the sum of the two elements of
the other might never start.  the subsequence
(> 2) 
𝐦𝐩
let ( = MidPoint(from, to),
Parallelism Expressions  let mp be the midpoint of from and to
𝐱𝟏
Note that parallelism is different from general concurrency, = Accumulate(seq, from, mp) ||
𝐍𝐮𝐦𝐛𝐞𝐫
which is discussed below.  compute the sum of
 the first subsequence in parallel with
{discard || value } 𝐱𝟐
= Accumulate(seq, mp, to))
𝐍𝐮𝐦𝐛𝐞𝐫
The expressions discard and value must be  the sum of the second subsequence
evaluated using mandatory concurrency in the sense return x1+x2
that either one can rely on effects eventually produced by  return the sum of the subsequences
evaluating the other and furthermore:
1. A return value of discard is discarded and
the response (if any) of value passed back for futuresponsor expression
{discard || value }.
A future in ActorScript is a derivative of the futures
2. If the evaluation of discard or value originally developed in [Baker and Hewitt 1977]. A future
generates an exception then any such exception of expression immediately returns an Actor (called
can be rethrown for {discard || value }.
theFuture) that behaves like the value of expression
should it ever be produced. Furthermore, theFuture can
See the section below on sponsors for a meta-circular be a derivative in the sense that requests sent to can result
implementation. in the creation of new futures for the results of those
requests, etc.
Sponsors are discussed in a section below.

Note that using a future is the only way to Illustration:
generate non-hierarchical control structure. The following implements an event stream (sequence) for
the leaves of a tree (see below):
This is because the expressions
 [expression1 , …, expressioni ,… expressionn ] 𝐭 
Fringe( )
?∗
 {discard || value} 𝐓𝐫𝐞𝐞
 {discard , value}
 a sequence of the contents of the
 {discard ; value}
 nodes of a tree
do not respond unless all their subexpressions cases t
respond. 𝐭
 return [tGetContents< >]
𝐋𝐞𝐚𝐟
𝐭
 return
Illustration: 𝐍𝐨𝐝𝐞
The procedure Accumulate in parallel adds up all the [future Fringe(tGetLeft< >)
numbers of the subsequence between two indices in 
sequence. future Fringe(tGetRight< >)]
𝐬𝐞𝐪 𝐟𝐫𝐨𝐦, 𝐭𝐨 
Accumulate( )
𝐍𝐮𝐦𝐛𝐞𝐫 𝐍𝐮𝐦𝐛𝐞𝐫 𝐍𝐮𝐦𝐛𝐞𝐫
Tree  interface
∗
 seq is a sequence of numbers
cases to-from  Tree is defined to be a new interface
0  return 0
 return 0 because the subsequence is empty Node  interface extends Tree
1  return seq[from]  Node is an interface that extends the Tree interface
 return the only element of the subsequence
2  return seq[from]+ seq[from+1] GetLeft< >
 return the sum of the two elements of 𝐓𝐫𝐞𝐞
 the subsequence GetRight< >
(> 2)  𝐓𝐫𝐞𝐞
𝐦𝐩
let = MidPoint(from, to)
𝐈𝐧𝐭𝐞𝐠𝐞𝐫 Leaf  interface extends Tree
 let mp be the midpoint of from and to
 Leaf is an interface that extends the Tree interface
return
(future Accumulate(seq, from, mp)) + GetContents< >
Accumulate(seq, mp, to)) ?
 return the sum of the subsequences
Below is an implementation of trees:
Eventing
Eventing is implemented by providing events as elements
of sequences. Subscribing to events is accomplished by
consuming an event streams. For example a stream of the
leaves of a tree can be implemented as follows:

Illustration: A Response is one of the following:
The following implements trees: 1. Returned<value>
𝐥𝐞𝐟𝐭𝐒𝐮𝐛𝐭𝐫𝐞𝐞, 𝐫𝐢𝐠𝐡𝐭𝐒𝐮𝐛𝐭𝐫𝐞𝐞  2. Threw<exception>
CreateNode( )𝐍𝐨𝐝𝐞
𝐓𝐫𝐞𝐞
 create a node of a tree
behavior As explained earlier the EmptyEnv can be implemented as
follows:
implements Node 
GetLeft< > return leftSubTree EmptyEnv
𝐄𝐧𝐯
𝐓𝐫𝐞𝐞 behavior
GetRight< > return rightSubTree implements Env
𝐓𝐫𝐞𝐞 𝐢
Lookup< >  throw NotFound

CreateLeaf(contents) 𝐋𝐞𝐚𝐟 𝐢
Bind<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫 value>
 create a leaf of a tree 𝐄𝐧𝐯
behavior return CreateEnv(Binding, EmptyEnv)
implements Leaf
GetContents< > return contents Below is an implementation equivalent to the one above
? that uses customers explicitly:

EmptyEnv
𝐄𝐧𝐯
Co-routining behavior
implements Env
Co-routining is implemented as sequences. for example
Request<Lookup<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫>𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫> 
𝐢 𝐜
the procedure SameFringe below co-routines between two
sequences:  received a request to lookup the
identifier i and send a response to customer c
Illustration: c Threw<NotFound>
The following implements trees: send c the exception NotFound>
𝐢 𝐜
Request<Bind<𝐈𝐝𝐞𝐧𝐭𝐢𝐟𝐢𝐞𝐫value> 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫>
𝐟𝐢𝐫𝐬𝐭, 𝐬𝐞𝐜𝐨𝐧𝐝  𝐄𝐧𝐯
SameFringe( ) 𝐁𝐨𝐨𝐥𝐞𝐚𝐧  received a request to bind the identifier i to
𝐓𝐫𝐞𝐞
 test if two trees have the same fringe  value and send a response to customer c
return Fringe(first) = Fringe(second) cReturned<CreateEnv(
Binding,
EmptyEnv)>
Customers  is defined in terms of 

A customer is an Actor that can receive at most one Performatives are sent using  and received using .
response for a request.xiv The response is a returned value
or a thrown exception. Requests, returned values, and recipient  message
thrown exception are all called performatives. (See
Call the recipient with a Request to perform the
illustration just below.)
message and pass back the response..
A Performative is one of the following:

1. Request<message customer>
2. a Response (see below)

recipient message 
behavior Exceptions
implements Exp expression
>
𝐜
Request<Eval<e> catch
𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫
return pattern1 expression1
(recipient Eval<e> )  …
Request[(message Eval<e> ) c] ) patternn  expressionn
procedure(expression1 … expressionn) catch expressions are a standard programming

This is an ordinary procedure call. It can be considered language construct:
to be an abbreviation for If expression throws an exception that
procedure  [expression1 … expressionn] matches pattern1 then evaluate expression1
etc. up to if the exception matches patternn
then evaluate expressionn ; otherwise rethrow
 is defined in terms of ⇚ the exception CaseNotFound< >..
Communications are sent using ⇚ and received using

⇛. Concurrent Programming
Concurrency in ActorScript that goes beyond Logic
recipient  performative Programming is provided by the serializer expression, In
FIFO order, a serializer applies its current behavior to a
Send the recipient the performative. communication received which in turn produces the
behavior for the next communication.
recipient  performative 
behavior
implements Exp
𝐜 𝐬
Communication<Request<Eval<e> > >⇛
𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 𝐒𝐩𝐨𝐧𝐬𝐨𝐫
{(recipient Eval<e> ) ⇚
Communication<
Request <(performative Eval<e>) c>
s>,
return}

Illustration: Illustration:
An illustrative example is a simple account that can accumulate An illustrative example is a simple storage cell that can contain
numerical values The interface can be defined as follows: any Actor address of type t. The interface can be defined as
Account 
follows:
 Account is defined Cellt 

interface  Cell of type t is defined
 to be an interface with the following methods interface
 to be an interface with the following methods
Read< >
𝐍𝐮𝐦𝐛𝐞𝐫 Read< >
 Read< > message returns a number 𝐭
𝐝𝐞𝐥𝐭𝐚  Read< > message returns type t
Deposit< > 𝐧𝐞𝐱𝐭𝐂𝐨𝐧𝐭𝐞𝐧𝐭𝐬
𝐍𝐮𝐦𝐛𝐞𝐫 𝑣𝑜𝑖𝑑 Write< >
 Deposit message with delta 𝐭 𝑣𝑜𝑖𝑑
 returns void  Write message with nextContents of type t
 returns void
Below SimpleAccount is defined that implements Accumulaor:
SimpleAccount 
Below SimpleCellt is defined that implement Cellt
 SimpleAccount is defined SimpleCellt 

serializer  to be a serializer  SimpleCell of type t is defined
𝐛𝐚𝐥𝐚𝐧𝐜𝐞 serializer  to be a serializer
 with balance that is a number 𝐜𝐨𝐧𝐭𝐞𝐧𝐭𝐬
𝐍𝐮𝐦𝐛𝐞𝐫  with contents
implements Account  implement the Account 𝐭
interface implements Cellt  implement the Cellt interface
Read< > Read< >
𝐍𝐮𝐦𝐛𝐞𝐫 𝐭
return balance  return balance return contents  return contents
𝐝𝐞𝐥𝐭𝐚 𝐧𝐞𝐱𝐭𝐂𝐨𝐧𝐭𝐞𝐧𝐭𝐬
Deposit< > Write< >
𝐍𝐮𝐦𝐛𝐞𝐫 𝑣𝑜𝑖𝑑 𝐭 𝑣𝑜𝑖𝑑
return also become(balance=balance + delta) return also become (contents=nextContents)

 returns void also the next message is  returns void also the next message is
 processed with balance plus delta  processed with contents=nextContents
For example the following expression creates a cell x with initial For example the following expression creates a cell x with initial
contents 5 and then concurrently writes to it with the values 7 and contents 5 and then concurrently writes to it with the values 7 and
9. 9.
𝐱 𝐱
let = new SimpleAccount(balance=5); let = new SimpleCellInteger(contents=5);
𝐀𝐜𝐜𝐨𝐮𝐧𝐭 𝐂𝐞𝐥𝐥𝐈𝐧𝐭𝐞𝐠𝐞𝐫
{xDeposit<7>, xDeposit<9>, xRead< > } {xWrite<7>, xWrite<9>, xRead< > }
The value of the above expression is 21 regardless of the order The value of the above expression is 5, 7 or 9.
of internal operations On the other hand sequential evaluation proceeds as follows:
𝐱
let = new SimpleCellInteger(contents=5);
𝐂𝐞𝐥𝐥𝐈𝐧𝐭𝐞𝐠𝐞𝐫
{xWrite<7>; xWrite<9>; xRead< > }
The value of the above expression is 9.
The reason that serializer goes beyond the capabilities of

Logic Programming is that in general the order of arrival of
messages at a serializer cannot be deduced from previous
computational steps.

Serializing serializer variables methods 
Actor script provides concurrency primitive called behavior
serializers for serializing computation.xv Serializers are implements Exp
𝐞
Actors that process communications received in the order Eval<𝐄𝐧𝐯> 
in which they are received.
return Create(variables, methods, e)
A serializer binds the values of the initial values its

Crucial aspects of the evaluation of a variables in the environment.
communication expression of the form
𝐝𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧𝐬 𝐦𝐞𝐭𝐡𝐨𝐝𝐬 𝐞
recipient ⇚communication Create( , , )
where recipient is a serializer are the following: 𝐃𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧∗ 𝐌𝐞𝐭𝐡𝐨𝐝∗ 𝐄𝐧𝐯
1. The evaluation generates an event in behavior
the activation ordering (≈≈>) for [  initialValues]
recipient receiving communication return
2. If recipient is a serializer (see below), Behavior(methods,
Extend(declarations,
then the event is also in the arrival
initialValues,
ordering of recipient ( ). See e))
𝑟𝑒𝑐𝑖 𝑝𝑖𝑒𝑛𝑡
[Hewitt 2006b] and [Agha, Mason,
Smith, and Talcott 1997] for further
𝐝𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧𝐬 𝐢𝐧𝐢𝐭𝐢𝐚𝐥𝐢𝐳𝐞𝐫𝐬 𝐞
discussion on arrival orders. Extend( , , )
𝐃𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧∗ 𝐈𝐧𝐢𝐭𝐢𝐚𝐥𝐢𝐳𝐞𝐫 ∗ 𝐄𝐧𝐯
cases declarations
[]
serializer variables methods
cases initializers
Create a new Actor with local variables and methods [ ] return e
to process messages such that when a communication not [ ] throw TwoFewDeclarations< >
is received then try to apply each method in turn. 𝐝𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧 𝐫𝐞𝐬𝐭𝐃𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧
Methods are of following kinds:
[ 𝐃𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧 
𝐃𝐞𝐜𝐥𝐚𝐫𝐚𝐭𝐢𝐨𝐧∗
]
1. communicationPattern ⇛body is the most cases initializers
primitive. [ ]  throw TwoFewInitializers[ ]
𝐢𝐧𝐢𝐭𝐢𝐥𝐢𝐳𝐞𝐫 𝐫𝐞𝐬𝐭𝐈𝐧𝐢𝐭𝐢𝐥𝐢𝐳𝐞𝐫𝐬
2. commuicationPattern  body is used to bind the [𝐈𝐧𝐢𝐭𝐢𝐚𝐥𝐢𝐳𝐞𝐫 
𝐈𝐧𝐢𝐭𝐢𝐚𝐥𝐢𝐳𝐞𝐫𝐬∗
]
customer of the request in the body. It is implemented return
using Extend(restDeclarations, restInitializers)
Communication<communicationPattern sponsor> ⇛ … Bind<declaration initialize>
where communicationPattern is used as the pattern for
the communication.
3. messagePattern  body is used to bind
newsponsor serializer
messages in requests. It is implemented using A new construct creates a new serializer with initial
Request[messagePattern customer]  … behavior serializer.
where messagePattern is used as the pattern for
the message.
Note: in practice, serializers are typically

bound to identifiers using version and
configuration control.
When a serializer construct receives an Eval message, it

returns a serializer with its variables, methods and the
environment of the Eval message:

Return, Throw, and Become Commands
newsponsor serializer 
The various forms of return, throw, and become
behavior commands produce the outcomes.
implements Expression
Eval<e> return value
return
newsponsor Return value
SerializerBehavior(
current= serializerEval<e>
working=Null return value 
communications= [ ]) behavior
When an instance receives a communication, it sends the Eval<e>
𝐎𝐮𝐭𝐜𝐨𝐦𝐞
communication to its current behavior for processing and
return Returned<valueEval<e>>
then updates itself according to the result returned.
A serializer s (conceptually) processes throw exception

communications in the order of its arrival Throw exception
ordering ( ).
𝐬
 However the implementation is often optimized.
throw exception 
behavior
When a behavior receives a request to process a implements Expression
communication, it calls ProcessCommunication which
returns an Outcome.
Eval<e>
return
An Outcome is one of the following: Threw<exception Eval<e>>
1 Returned<value>
2 ReturnedAlsoBecame<exception update> return value also become next
3 Threw<exception>
4 ThrewAlsoBecame<exception update> Return value and also become next.
5 DidNotRespond< >
6 DidNotRespondAlsoBecame<update>
return value also become next 
where update is the next behavior of the behavior
serializer. implements Expression
Eval<e>
return
ReturnedAlsoBecame<value Eval<e>
𝐦𝐞𝐭𝐡𝐨𝐝𝐬 𝐞
Behavior(𝐌𝐞𝐭𝐡𝐨𝐝∗ , 𝐄𝐧𝐯
) next Eval<e>>
implements Behavior
behavior throw exception also become next
𝒄
Process<𝐂𝐨𝐦>
𝐎𝐮𝐭𝐜𝐨𝐦𝐞 Throw exception and also become next.
return ProcessCommunication(c, methods, e)

throw exception also become next  no response also become next
behavior Do not respond and also become <expression>next
Eval<e>
return no response also become next 
ThrewAlsoBecame<exception Eval<e> behavior
next Eval<e>> implements Expression
Eval<e>
no response return
DidNotRespondAlsoBecame<nextEval<e>>
Do not respond
no response 
behavior
Eval<e>
return DidNotRespond< >

𝐜 𝐦𝐞𝐭𝐡𝐨𝐝𝐬 𝐞 
ProcessCommunications( , , ) 𝐎𝐮𝐭𝐜𝐨𝐦𝐞
𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧 𝐌𝐞𝐭𝐡𝐨𝐝∗ 𝐄𝐧𝐯
cases methods
[ ]  throw NotApplicable<com>
 𝐫𝐞𝐬𝐭𝐌𝐞𝐭𝐡𝐨𝐝𝐬
𝐟𝐢𝐫𝐬𝐭𝐌𝐞𝐭𝐡𝐨𝐝
[ 𝐌𝐞𝐭𝐡𝐨𝐝 𝐌𝐞𝐭𝐡𝐨𝐝
] ∗
cases firstMethod
Method[ ]
𝐟𝐢𝐫𝐬𝐭𝐏𝐚𝐭𝐭𝐞𝐫𝐧 𝐟𝐢𝐫𝐬𝐭𝐁𝐨𝐝𝐲
“”
𝐏𝐚𝐭𝐭𝐞𝐫𝐧 𝐄𝐱𝐩𝐫𝐞𝐬𝐬𝐢𝐨𝐧
let {Communication<Request<message …>> = c;
𝐧𝐞𝐰𝐄
= firstPatternMatch<message e> };
𝐄𝐧𝐯
cases newE
null return ProcessCommunications(c, restMethods, e)
not null return firstBodyEval<newE>
Method[ ]
“”
let Communication<performative ?> = c;
𝐧𝐞𝐰𝐄
= firstPatternMatch<performative e>;
𝐄𝐧𝐯
cases newE
null  return ProcessCommunication(c, restMethods, e)
not null  return firstBodyEval<newE>
Method[ ]
“⇛”
𝐧𝐞𝐰𝐄
let = firstPatternMatch<c e>;
𝐄𝐧𝐯
cases newE
null return ProcessCommunications(c, restMethods, e)
not null  return firstBodyEval<newE>
A Relay is the means by which a simple serializer coordinates with its behavior by packaging the outcome returned by the
behavior together with the original customer of the request and sending them in a Relayed package to the serializer.xvi
𝐜
Relay(s, ) 
behavior
𝐫

𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞
cases r
𝐨
Returned< > {sReturned<Relayed<o c>>, no response}
𝐞
Threw< >  {cReturned<Threw<e>>, no response}
𝐄𝐱𝐜𝐞𝐩𝐭𝐢𝐨𝐧

SerializerBehavior 
serializer
current current behavior
𝐰𝐨𝐫𝐤𝐢𝐧𝐠
 working communication
𝐑𝐞𝐪𝐮𝐢𝐬𝐢𝐭𝐢𝐨𝐧
𝐩𝐞𝐧𝐝𝐢𝐧𝐠
pending communications
𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧∗
𝐜𝐨𝐦
⇛
𝐂𝐨𝐦𝐦𝐮𝐧𝐢𝐜𝐚𝐭𝐢𝐨𝐧
cases com
𝐜𝐮𝐬𝐭
Communication<Request<? 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫
>…> 
cases working
null  {future currentRequest<Process<com> Relay(self, cust)> ,
no response also become SerializerBehavior(working=r)}
not null no response also become SerializerBehavior(pending=[pending com])
𝐨 𝐜𝐮𝐬𝐭
Communication<Returned<Relayed< 𝐎𝐮𝐭𝐜𝐨𝐦𝐞 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫
>>…> 
cases o
ReturnedAlsoBecame<value next> 
cases pending
[ ]  {custReturned<value>, no response also become SerializerBehavior(current=next, working=null )}
𝐜
not [ ]  let ([first  rest]=pending, Communication<Request<? >…> = first)
{ custReturned<value> , future currentRequest<Process<first> Relay(self, c)> ,
no response also become SerializerBehavior(current=next, working=first, pending=rest)}
Returned<value> 
cases pending
[ ]  {{cReturned<value>, no response also become SerializerBehavior( working=null )}
𝐜
not [ ] let ([first  rest]=pending, Communication<Request<? >…> = first)
{custReturned<value> , future currentRequest<Process<first> Relay(self, c)> ,
no response also become SerializerBehavior(working=first, pending=rest)}
Threw<e> 
cases pending
[ ]  {cThrew<e>, no response also become SerializerBehavior ( working=null )}
𝐜
not [ ]  let ([first  rest]=pending, Communication<Request<? >…> = first)
{ custThrew<e> , future currentRequest<Process<first> Relay(self, c)> ,
no response also become SerializerBehavior (working=first, pending=rest)}
DidNotRespond< > 
cases pending
[ ]  no response also become SerializerBehavior ( working=null )
𝐜
not [ ]  let ([first  rest]=communications, Communication<Request<? >…> = first)
{future currentRequest<Process<first> Relay(self, c)> ,
no response also become SerializerBehavior(working=first, pending=rest)}
DidNotRespondAlsoBecame<next> 
cases pending
[ ]  no response also become SerializerBehavior (current=next, working=null )
𝐜
not [ ]  let (<first  rest]=pending, Communication<Request<? >…> = first)
{future currentRequest<Process<first> Relay(self, c)> ,
no response also become SerializerBehavior(current=next, working=first, pending=rest)}

An implementation of Futures
Below is a very simple minded implementation of futures. In practice, it needs to be heavily optimized.
futuresponsor expression 
behavior
𝐜𝐮𝐬𝐭
𝐑𝐞𝐪𝐮𝐞𝐬𝐭 < 𝐄𝐯𝐚𝐥 < 𝐞 > > 
let f  new FutureBehavior(hasResponse= false,
repackagerThenResponse = r,
customers=[ ],
derivatives = [ ] )
r  new Repackager(f)),
note that f and r are defined in terms of each other
{expression ⇚
Communication<Request<Eval<e> f>sponsor>,
note that because of the use of comma (,) above that
concurrency is not forced in using a future
cust  Returned< f >,
no response}

FutureBehavior 
serializer
𝐡𝐚𝐬𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞
true after response has been received
Boolean
repackagerThenResponse initially the repackager customer and
 then the response when hasResponse becomes true
𝐜𝐮𝐬𝐭𝐨𝐦𝐞𝐫𝐬
 pending customers
𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 ∗
𝐝𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞𝐬
 derivative futures
𝐃𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞 ∗
𝐜𝐨𝐦
⇛
cases com
𝐜𝐮𝐬𝐭 𝐬
Communication<Request<m 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫> 𝐒𝐩𝐨𝐧𝐬𝐨𝐫> 
cases m
bottom< > 
 bottom< > message is used by system primitives to request values from futures
cases hasResponse
false no response also become(customers = [cust  customers])
true  cases repackagerThenResponse
Returned<v>  {cust  Returned<v>, no response}
Threw<e>  {cust  Threw<e>, no response}
not bottom< > 
cases hasResponse
false 
{let (f new DerivativeBehavior(Communication<Request m r> s>)
(hasResponse=false , repackagerThenResponse=r,
customers=[ ],
derivatives = [f  derivatives],
pending= Communication<Request m r> s>)),
note that f and r are defined in terms of each other
cust  Returned< f >, no response}
true  cases repackagerThenResponse
Returned<v>  {v ⇚com, no response}
𝐫
Communication<Returned<Responded< >>>
{ProcessCustomersAndDerivatives(r, customers, derivatives),
no response also become(customers=[ ], derivatives=[ ],
hasResponse=true, repackagerThenResponse=r)}

DerivativeBehavior 
serializer
𝐡𝐚𝐬𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞
true after response has been received
Boolean
futureThenResponse initially the future from which derived and
 then the response when hasResponse becomes true
𝐜𝐮𝐬𝐭𝐨𝐦𝐞𝐫𝐬
pending customers
𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 ∗
𝐝𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞𝐬
𝐃𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞 ∗
 derivative futures
𝐩𝐞𝐧𝐝𝐢𝐧𝐝
Communication
 pending communication
𝐜𝐨𝐦
⇛
cases com
𝐜𝐮𝐬𝐭 𝐬
Communication<Request<m 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 > 𝐒𝐩𝐨𝐧𝐬𝐨𝐫> 
cases m
Bottom< > 
 Bottom< > message is used by system primitives to request values from futures
cases hasResponse
false no response also become(customers = [cust  customers])
true  cases futureThenResponse
Returned<v>  {cust  Returned<v>, no response}
𝐫
Forward< >
 Forward message is used by futures to forward responses to derivatives
cases r
Returned<v>  {v ⇚pending, cust  Returned< >, no response also become(pending=null )}
Threw<e>  {ProcessCustomersAndDerivatives(r, customers, derivatives),
cust  Returned< >,
no response also become(hasResponse=True, futureThenResponse=r,
customers=[ ], derivatives=[ ],)}
none of above 
cases hasResponse
false 
{let (f new DerivativeBehavior
(hasResponse=False , futureThenResponse= self,
customers=[ ],
derivatives=[ ]
pending= Communication<Request m r> s>),
 note that f and r are defined in terms of each other
{cust  Returned< f >, no response}
true  cases futureThenResponse
Returned<v>  {v ⇚com, no response}
𝐫
Communication<Returned<Responded< 𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 >>>
{ProcessCustomersAndDerivatives(r, customers, derivatives),
no response also become(hasResponse=true, futureThenResponse=r, customers=[ ], derivatives=[ ] )}

A Repackager is the means by which a response is safely sent back to a future by repackaging it so that it cannot be faked by
others.
𝐜𝐮𝐬𝐭
Repackager( )
serializer
𝐫
 {custReturned<Responded<r> >, no response}
𝐫 𝐜𝐮𝐬𝐭𝐨𝐦𝐞𝐫𝐬 𝐝𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞𝐬 
ProcessCustomersAndDerivatives( , , ) 𝑣𝑜𝑖𝑑
𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫∗ 𝐃𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞∗
{ProcessCustomers(r, customers),
return ProcessDerivatives(r, derivatives)}
𝐫 𝐜𝐮𝐬𝐭𝐨𝐦𝐞𝐫𝐬 
ProcessCustomers( , ) 𝐯𝐨𝐢𝐝
𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 ∗
cases customers
[ ] return
[first  rest] 
{cases r
Returned<v>  first Returned<v>
Threw<e>  firstThrew<e>,
return ProcessCustomers(r, rest)}
𝐫 𝐝𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞𝐬 
ProcessDerivatives( , ) 𝐯𝐨𝐢𝐝
𝐑𝐞𝐬𝐩𝐨𝐧𝐬𝐞 𝐃𝐞𝐫𝐢𝐯𝐚𝐭𝐢𝐯𝐞 ∗
cases derivatives
[ ] return
[first  rest] 
{first Forward<r>,
return ProcessDerivatives(r, rest)}

Sponsors
Sponsors are used to provide resources to computation including the following:
 Storage
 Processing
 Communications
A CutOffSponsor that can be told to cut off resources by sending it a CutOff message can be implemented as follows:
𝐬 
CutOffSponsor( ) 𝐒𝐩𝐨𝐧𝐬𝐨𝐫
𝐒𝐩𝐨𝐧𝐬𝐨𝐫
serializer
𝐚𝐥𝐫𝐞𝐚𝐝𝐲𝐂𝐮𝐭𝐎𝐟𝐟
𝐁𝐨𝐨𝐥𝐞𝐚𝐧
𝐫

𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐑𝐞𝐪𝐮𝐞𝐬𝐭
cases alreadyCutOff
true  throw Refused<>
false  return sr
𝐫

𝑛𝑜𝑡 𝐑𝐞𝐬𝐨𝐮𝐫𝐜𝐞𝐑𝐞𝐪𝐮𝐞𝐬𝐭
cases r
CutOff<>  return also become (alreadyCutOff=true)
not CutOff<>  return sr
CutOff Sponsors can be used in the implementation of compound expressions as follows:
{discard ; value }
The expressions discard and value are evaluated sequentially, i.e., evaluation of value does not begin before discard
has responded with one of the following:
3. A return value that is discarded and then value is evaluated to produce the response (if any) for {discard ;
value }..
4. An exception that is rethrown to produce the response for {discard ; value } and the evaluation of value is
never begun.

{discard ; value } 
behavior
𝐞 𝐜𝐮𝐬𝐭
Request<Eval< > >> 
𝐄𝐧𝐯 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫
return
discard <Request<Eval<e SemicolonCustomer(cust e value)>>
𝐜𝐮𝐬𝐭 𝐞 𝐯𝐚𝐥𝐮𝐞𝐄𝐱𝐩𝐫𝐞𝐬𝐬𝐢𝐨𝐧 
SemicolonCustomer(𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 𝐄𝐧𝐯 𝐄𝐱𝐩
) 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫
behavior
implements Customer
Thrown<exception> 
{cust  Thrown<exception>, no response}
Returned<v> 
{valueExpression  Request<Eval<e> cust>, no response}
{discard , value }
Evaluation of expressions discard, and value can be interleaved.. i.e. there are no restrictions on how
discard and value are evaluated except that:
4. A return value of discard is discarded and the response (if any) of value passed back for
{discard , value }.
5. If the evaluation of discard or value generates an exception then any such exception can be
rethrown for
{discard , value }.
6. If there is no response from evaluating discard or value , then evaluation of the other might never
start.

{discard , value } 
behavior
𝐞 𝐜𝐮𝐬𝐭 𝐬
Communication<Request<Eval< > > >⇛
𝐄𝐧𝐯 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 𝐒𝐩𝐬𝐨𝐧𝐬𝐨𝐫
let (cutOffSponsor = new (CutOffSponsor(s )) (alreadyCutOff=false)
valueCust = new (valueCustomer(cust cutOffSponsor))
(alreadyDiscarded=false, haveValue=false),
discardCust = discardCustomer(valueCust cutOffSponsor))
{discard ⇚ Communication<Request<Eval<e discardCust> cutOffSponsor >,
value ⇚ Communication<Request<Eval<e valueCust> cutOffSponsor >,
no response}
discardCustomer(valueCust cutOffSponsor) 
behavior
Thrown<e>  {cutOffSponsor  CutOff<>; valueCust  Thrown<e>, no response}
Returned<v> 
{valueCust  Discarded<>; no response}
valueCustomer(cust commaSponsor) 
serializer
𝐚𝐥𝐫𝐞𝐚𝐝𝐲𝐃𝐢𝐬𝐜𝐚𝐫𝐝𝐞𝐝
𝐡𝐚𝐯𝐞𝐕𝐚𝐥𝐮𝐞
value
Thrown<e> 
{commaSponsor  CutOff<>; cust  Thrown<e>; no response}
Returned<v> 
{commaSponsor CutOff<>;
cases alreadyDiscarded
true  {cust Returned<v>, no response}
false  no response also become(haveValue=true, value=v)}
Discarded<> 
cases haveValue
True  {cust  Returned<value>, return}
False no response also become(alreadyDiscarded=true)

{discard || value }
The expressions discard and value must be evaluated using mandatory concurrency in the sense that either one
can rely on effects eventually produced by evaluating the other and furthermore:
3. A return value of discard is discarded and the response (if any) of value passed back for
4. If the evaluation of discard or value generates an exception then any such exception can be rethrown for
{discard || value } 
behavior
𝐞 𝐜𝐮𝐬𝐭 𝐬
Communication<Request<Eval<𝐄𝐧𝐯 > 𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 > 𝐒𝐩𝐬𝐨𝐧𝐬𝐨𝐫
>⇛
let (cutOffSponsor= new (CutOffSponsor(s )) (alreadyCutOff=false)
valueCust= new (valueCustomer(cust cutOffSponsor))
(alreadyDiscarded=false, haveValue=false),
discardCust = discardCustomer(valueCust cutOffSponsor))
{discard ⇚ Communication<Request<Eval<e discardCust> cutOffSponsor> ||
value ⇚ Communication<Request<Eval<e valueCust> cutOffSponsor >,
no response}
discardCustomer(valueCust cutOffSponsor) 
behavior
Thrown<e>  {cutOffSponsor  CutOff<>; c  Thrown<e>, no response}
Returned<v>  {valueCust Discarded<>; no response}
valueCustomer(cust commaSponsor) 
serializer
𝐚𝐥𝐫𝐞𝐚𝐝𝐲𝐃𝐢𝐬𝐜𝐚𝐫𝐝𝐞𝐝
𝐡𝐚𝐯𝐞𝐕𝐚𝐥𝐮𝐞
value
Thrown<e>  {commaSponsor CutOff<>; cust  Thrown<e>; no response}
Returned<v> 
{commaSponsor CutOff<>;
cases alreadyDiscarded
True  {cust  Returned<v>, no response}
False  no response also become (haveValue=True, value=v)}
Discarded<> 
cases haveValue
True  {cust  Returned<value>, return}
False  no response also become(alreadyDiscarded=true)

Logic Programming
This section is included to illustrate how ActorScript as Goals
defined above can be used to implement a simple Logic
Programming language. 𝑝𝑟𝑜𝑣𝑒𝑛𝑎𝑛𝑐𝑒
?𝑡ℎ𝑒𝑜𝑟𝑦 goal
𝑝𝑟𝑜𝑣𝑒𝑛𝑎𝑛𝑐𝑒 Establish goal with provenance to be proved in
├𝑡ℎ𝑒𝑜𝑟𝑦 sentence
theory
Assert sentence with provenance in theory.
𝑝𝑟𝑜𝑣𝑒𝑛𝑎𝑛𝑐𝑒
?𝑡ℎ𝑒𝑜𝑟𝑦 goal 
├𝑡ℎ𝑒𝑜𝑟𝑦 sentence  behavior
behavior Eval<e> 
implements Expression return
Eval<e>  (theory Eval<e>) ? <provenance goal e>
return
(theory Eval<e>) ├ <sentenceEval<e>
provenanceEval<e> > 𝑝𝑟𝑜𝑣𝑒𝑛𝑎𝑛𝑐𝑒
?𝑡ℎ𝑒𝑜𝑟𝑦 goal then expression
Establish goal with provenance to be proved in
theory and when established evaluate expression.
Forward Chaining
├𝑡ℎ𝑒𝑜𝑟𝑦 sentence  expression
Forward Chaining: when a sentence matches ?𝑡ℎ𝑒𝑜𝑟𝑦 goal then expression 
sentence with provenance in theory, evaluate behavior
expression. implements Expression
Eval[e] 
return
├𝑡ℎ𝑒𝑜𝑟𝑦 sentence  expression  (theory Eval<e>) 
?<provenance goal expression e>
behavior
Eval<e> 
return Illustration:
(<theory> Eval<e>)  {
?<sentence provenance expression e> ├𝑇
𝐓𝐡𝐞𝐑𝐞𝐩𝐮𝐛𝐥𝐢𝐜
Human[Socrates] ;
𝐓𝐡𝐞𝐑𝐞𝐩𝐮𝐛𝐥𝐢𝐜
├𝑇 Human[Plato] ;
Illustration: 𝐩
? 𝑇 Human [h] then Collect(h) }
𝐩 𝐇𝐮𝐦𝐚𝐧𝐈𝐧𝐟𝐞𝐫𝐬𝐌𝐨𝐫𝐭𝐚𝐥(𝐩)
├ 𝑇 Human[x]  ├ 𝑇 Mortal[x] will result in concurrently calling Collect with the
arguments Socrates and Plato

Garst found numerous bugs and made valuable comments
Backward Chaining including information on the development of interfaces.
?𝑡ℎ𝑒𝑜𝑟𝑦 goal  expression Bibliography
Backward Chaining: when a goal matches goal with Hal Abelson and Gerry Sussman Structure and
provenance in theory , evaluate expression. Interpretation of Computer Programs 1984.
Gul Agha. Actors: A Model of Concurrent Computation in
Distributed Systems Doctoral Dissertation. 1986.
Gul Agha, Ian Mason, Scott Smith, and Carolyn Talcott.
“A foundation for Actor computation.” Journal of
?𝑡ℎ𝑒𝑜𝑟𝑦 goal  expression  Functional Programming. 1997.
Joe Armstrong History of Erlang HOPL III. 2007.
behavior William Athas and Charles Seitz Multicomputers:
implements Expression message-passing concurrent computers IEEE Computer
Eval<e>  August 1988.
return William Athas and Nanette Boden Cantor: An Actor
(theory Eval<e>)  Programming System for Scientific Computing in
?<goal provenance expression e> Proceedings of the NSF Workshop on Object-Based
Concurrent Programming. 1988. Special Issue of
SIGPLAN Notices.
Russ Atkinson. Automatic Verification of Serializers MIT
Illustration: Doctoral Dissertation. June, 1980.
𝐩
? 𝑇 Mortal [x]  Henry Baker. Actor Systems for Real-Time Computation
MIT EECS Doctoral Dissertation. January 1978.
𝐌𝐨𝐫𝐭𝐚𝐥𝐈𝐧𝐟𝐞𝐫𝐫𝐞𝐝𝐁𝐲𝐇𝐮𝐦𝐚𝐧(𝐩)
?𝑇 Human [x] Henry Baker and Carl Hewitt The Incremental Garbage
Collection of Processes Proceeding of the Symposium
on Artificial Intelligence Programming Languages.
SIGPLAN Notices 12, August 1977.
Acknowledgment Paul Baran. On Distributed Communications Networks
IEEE Transactions on Communications Systems. March
Important contributions to the semantics of Actors have
1964.
been made by: Gul Agha, Beppe Attardi, Henry Baker,
Gerry Barber. Reasoning about Change in Knowledgeable
Will Clinger, Irene Greif, Carl Manning, Ian Mason, Ugo
Montanari, Maria Simi, Scott Smith, Carolyn Talcott, Office Systems MIT EECS Doctoral Dissertation. August
1981.
Prasanna Thati, and Aki Yonezawa.
Peter Bishop Very Large Address Space Modularly
Extensible Computer Systems MIT EECS Doctoral
Important contributions to the implementation of Actors
Dissertation. June 1977.
have been made by: Bill Athas, Russ Atkinson, Beppe
Andreas Blass, Yuri Gurevich, Dean Rosenzweig, and
Attardi, Henry Baker, Gerry Barber, Peter Bishop, Nanette
Benjamin Rossman (2007a) Interactive small-step
Boden, Jean-Pierre Briot, Bill Dally, Peter de Jong, Jessie
algorithms I: Axiomatization Logical Methods in
Dedecker, Ken Kahn, Henry Lieberman, Carl Manning, Computer Science. 2007.
Mark S. Miller, Tom Reinhardt, Chuck Seitz, Richard Andreas Blass, Yuri Gurevich, Dean Rosenzweig, and
Steiger, Dan Theriault, Mario Tokoro, Darrell Woelk, and Benjamin Rossman (2007b) Interactive small-step
Carlos Varela. algorithms II: Abstract state machines and the
characterization theorem. Logical Methods in Computer
Research on the Actor model has been carried out at Science. 2007.
Caltech Computer Science, Kyoto University Tokoro Per Brinch Hansen Monitors and Concurrent Pascal: A
Laboratory, MCC, MIT Artificial Intelligence Laboratory, Personal History CACM 1996.
SRI, Stanford University, University of Illinois at Urbana- Don Box, David Ehnebuske, Gopal Kakivaya, Andrew
Champaign Open Systems Laboratory, Pierre and Marie Layman, Noah Mendelsohn, Henrik Nielsen, Satish
Curie University (University of Paris 6), University of Thatte, Dave Winer. Simple Object Access Protocol
Pisa, University of Tokyo Yonezawa Laboratory and (SOAP) 1.1 W3C Note. May 2000.
elsewhere. Jean-Pierre Briot. Acttalk: A framework for object-oriented
concurrent programming-design and experience 2nd
The members of the Silicon Valley Friday AM group made France-Japan workshop. 1999.
valuable suggestions for improving this paper. Blaine

Jean-Pierre Briot. From objects to Actors: Study of a Irene Greif. Semantics of Communicating Parallel
limited symbiosis in Smalltalk-80 Rapport de Recherche Professes MIT EECS Doctoral Dissertation. August
88-58, RXF-LITP. Paris, France. September 1988. 1975.
Luca Cardelli, James Donahue, Lucille Glassman, Mick Pat Hayes Some Problems and Non-Problems in
Jordan, Bill Kalsow, Greg Nelson. Modula-3 report Representation Theory AISB. Sussex. July, 1974
(revised) DEC Systems Research Center Research Werner Heisenberg. Physics and Beyond: Encounters and
Report 52. November 1989. Conversations translated by A. J. Pomerans (Harper &
Luca Cardelli and Andrew Gordon Mobile Ambients Row, New York, 1971), pp. 63 – 64.
FoSSaCS‟98. Carl Hewitt, Peter Bishop and Richard Steiger. A Universal
Alonzo Church The Calculi of Lambda-Conversion Modular Actor Formalism for Artificial Intelligence
Princeton University Press. 1941. IJCAI‟73.
Will Clinger. Foundations of Actor Semantics MIT Carl Hewitt. Viewing Control Structures as Patterns of
Mathematics Doctoral Dissertation. June 1981. Passing Messages AI Journal. June 1977.
Tyler Close Web-key: Mashing with Permission Carl Hewitt, et al. Actor Induction and Meta-evaluation
WWW‟08. Conference Record of ACM Symposium on Principles
Ole-Johan Dahl and Kristen Nygaard. “Class and subclass of Programming Languages, January 1974.
declarations” IFIP TC2 Conference on Simulation Carl Hewitt and Henry Lieberman. Design Issues in
Programming Languages. May 1967.
Parallel Architecture for Artificial Intelligence MIT AI
William Dally and Wills, D. Universal mechanisms for
memo 750. Nov. 1983.
concurrency PARLE „89.
Carl Hewitt, et al. Behavioral Semantics of Nonrecursive
William Dally, et al. The Message-Driven Processor: A
Control Structure Proceedings of Colloque sur la
Multicomputer Processing Node with Efficient
Programmation, April 1974.
Mechanisms IEEE Micro. April 1992.
Carl Hewitt. How to Use What You Know IJCAI.
Jack Dennis and Earl Van Horn. Programming Semantics
September, 1975.
for Multiprogrammed Computations CACM. March
Carl Hewitt and Henry Baker Laws for Communicating
1966.
Parallel Processes IFIP-77, August 1977.
A. Fine The Shaky Game: Einstein Realism and the
Carl Hewitt. Viewing Control Structures as Patterns of
Quantum Theory University of Chicago Press, Chicago,
Passing Messages AI Memo 410. December 1976.
1986.
Journal of Artificial Intelligence. June 1977.
Frederic Fitch. Symbolic Logic: an Introduction. Ronald
Carl Hewitt and Russ Atkinson. Specification and Proof
Press. 1952
Nissim Francez, Tony Hoare, Daniel Lehmann, and Techniques for Serializers IEEE Journal on Software
Willem-Paul de Roever. Semantics of nondeterminism, Engineering. January 1979.
concurrency, and communication Journal of Computer Carl Hewitt, Beppe Attardi, and Henry Lieberman.
and System Sciences. December 1979. Delegation in Message Passing Proceedings of First
Christopher Fuchs Quantum mechanics as quantum International Conference on Distributed Systems
information (and only a little more) in A. Khrenikov Huntsville, AL. October 1979.
(ed.) Quantum Theory: Reconstruction of Foundations Carl Hewitt and Gul Agha. Guarded Horn clause
(Växjo: Växjo University Press, 2002). languages: are they deductive and Logical? in Artificial
Blaine Garst. Origin of Interfaces Email to Carl Hewitt on Intelligence at MIT, Vol. 2. MIT Press 1991.
October 2, 2009. Carl Hewitt and Jeff Inman. DAI Betwixt and Between:
Elihu M. Gerson. Prematurity and Social Worlds in From "Intelligent Agents" to Open Systems Science
Prematurity in Scientific Discovery. University of IEEE Transactions on Systems, Man, and Cybernetics.
California Press. 2002. Nov./Dec. 1991.
Andreas Glausch and Wolfgang Reisig. Distributed Carl Hewitt and Peter de Jong. Analyzing the Roles of
Abstract State Machines and Their Expressive Power Descriptions and Actions in Open Systems Proceedings
Informatik Berichete 196. Humboldt University of Berlin. of the National Conference on Artificial Intelligence.
January 2006. August 1983.
Adele Goldberg and Alan Kay (ed.) Smalltalk-72 Carl Hewitt. (2006). “What is Commitment? Physical,
Instruction Manual SSL 76-6. Xerox PARC. March Organizational, and Social” COIN@AAMAS‟06.
1976. (Revised version to be published in Springer Verlag
Cordell Green. Application of Theorem Proving to Problem Lecture Notes in Artificial Intelligence. Edited by Javier
Solving IJCAI’69. Vázquez-Salceda and Pablo Noriega. 2007) April 2006.
Irene Greif and Carl Hewitt. Actor Semantics of Carl Hewitt (2007a). “Organizational Computing Requires
PLANNER-73 Conference Record of ACM Symposium Unstratified Paraconsistency and Reflection”
on Principles of Programming Languages. January 1975. COIN@AAMAS. 2007.

Carl Hewitt (2008a) Norms and Commitment for ORGs Bill Kornfeld and Carl Hewitt. The Scientific Community
(Organizations of Restricted GeneralityTM): Direct Metaphor IEEE Transactions on Systems, Man, and
LogicTM and Participatory Argument Checking ArXiv Cybernetics. January 1981.
0906.2756. Bill Kornfeld. Parallelism in Problem Solving MIT EECS
Carl Hewitt (2008b) “Large-scale Organizational Doctoral Dissertation. August 1981.
Computing requires Unstratified Reflection and Strong Robert Kowalski Algorithm = Logic + Control CACM.
Paraconsistency” Coordination, Organizations, July 1979.
Institutions, and Norms in Agent Systems III Jaime Robert Kowalski. Response to questionnaire Special Issue
Sichman, Pablo Noriega, Julian Padget and Sascha on Knowledge Representation. SIGART Newsletter.
Ossowski (ed.). Springer-Verlag. February 1980.
http://organizational.carlhewitt.info/
Robert Kowalski (1988a) The Early Years of Logic
Carl Hewitt (2008c) “Middle History of Logic
Programming CACM. January 1988.
Programming” ArXiv 0904.3036.
Carl Hewitt (2008d). ORGs (Organizations of Restricted Robert Kowalski (1988b) Logic-based Open Systems
GeneralityTM): Direct LogicTM and Participatory Representation and Reasoning. Stuttgart Conference
Argument Checking Google Knol. Workshop on Discourse Representation, Dialogue
Carl Hewitt (2008e). ORGs for Scalable, Robust, Privacy- tableaux and Logic Programming. 1988.
Friendly Client Cloud Computing IEEE Internet Peter Landin. “A Generalization of Jumps and Labels”
Computing September/October 2008. UNIVAC Systems Programming Research Report.
Carl Hewitt (2008f) Common sense for concurrency and August 1965. (Reprinted in Higher Order and Symbolic
inconsistency tolerance using Direct LogicTM ArXiv Computation. 1998)
0812.4852. Edward Lee and Stephen Neuendorffer (June 2004).
Carl Hewitt (2009a) Perfect Disruption: The Paradigm Classes and Subclasses in Actor-Oriented Design.
Shift from Mental Agents to ORGs IEEE Internet Conference on Formal Methods and Models for
Computing. Jan/Feb 2009. Codesign (MEMOCODE).
Carl Hewitt (2009b) A historical perspective on developing Steven Levy Hackers: Heroes of the Computer Revolution
foundations for client cloud computing: The Paradigm Doubleday. 1984.
Shift from “Inconsistency Denial” to “Semantic Henry Lieberman. An Object-Oriented Simulator for the
Integration" (Revised version of “Development of Logic Apiary Conference of the American Association for
Programming: What went wrong, What was done about Artificial Intelligence, Washington, D. C., August 1983
it, and What it might mean for the future” AAAI Henry Lieberman. Thinking About Lots of Things at Once
Workshop on What Went Wrong. AAAI-08.) ArXiv without Getting Confused: Parallelism in Act 1 MIT AI
0901.4934. memo 626. May 1981.
Tony Hoare Monitors: An Operating System Structuring Henry Lieberman. A Preview of Act 1 MIT AI memo 625.
Concept CACM. October 1974. June 1981.
Tony Hoare. Communicating sequential processes CACM. Henry Lieberman and Carl Hewitt. A real Time Garbage
August 1978. Collector Based on the Lifetimes of Objects CACM June
Tony Hoare Communicating Sequential Processes Prentice 1983.
Hall. 1985. Barbara Liskov and Liuba Shrira Promises: Linguistic
W. Horwat, Andrew Chien, and William Dally. Experience Support for Efficient Asynchronous Procedure Calls
with CST: Programming and Implementation PLDI. SIGPLAN‟88.
1989. Carl Manning. Traveler: the Actor observatory ECOOP
M. Jammer The EPR Problem in Its Historical 1987. Also appears in Lecture Notes in Computer
Development in Symposium on the Foundations of Science, vol. 276.
Modern Physics: 50 years of the Einstein-Podolsky- Carl Manning,. Acore: The Design of a Core Actor
Rosen Gedankenexperiment, edited by P. Lahti and P. Language and its Compile Masters Thesis. MIT EECS.
Mittelstaedt (World Scientific, Singapore, 1985), pp. 129 May 1987.
– 149. Satoshi Matsuoka and Aki Yonezawa. Analysis of
Ken Kahn. A Computational Theory of Animation MIT Inheritance Anomaly in Object-Oriented Concurrent
EECS Doctoral Dissertation. August 1979. Programming Languages Research Directions in
Alan Kay. “Personal Computing” in Meeting on 20 Years Concurrent Object-Oriented Programming MIT Press.
of Computing Science Instituto di Elaborazione della 1993.
Informazione, Pisa, Italy. 1975. John McCarthy Programs with common sense Symposium
http://www.mprove.de/diplom/gui/Kay75.pdf on Mechanization of Thought Processes. National
Frederick Knabe A Distributed Protocol for Channel- Physical Laboratory, UK. Teddington, England. 1958.
Based Communication with Choice PARLE‟92. John McCarthy, Paul Abrahams, Daniel Edwards, Timothy
Hart, and Michael Levin. Lisp 1.5 Programmer’s

Manual MIT Computation Center and Research Gerry Sussman and Guy Steele Scheme: An Interpreter for
Laboratory of Electronics. 1962. Extended Lambda Calculus AI Memo 349. December,
John McCarthy. Situations, actions and causal laws 1975.
Technical Report Memo 2, Stanford University Artificial Daniel Theriault. A Primer for the Act-1 Language MIT AI
Intelligence Laboratory. 1963. memo 672. April 1982.
John McCarthy and Patrick Hayes. Some Philosophical Daniel Theriault. Issues in the Design and Implementation
Problems from the Standpoint of Artificial Intelligence of Act 2 MIT AI technical report 728. June 1983.
Machine Intelligence 4. Edinburgh University Press. Hayo Thielecke An Introduction to Landin’s
1969. “A Generalization of Jumps and Labels” Higher-Order and
Giuseppe Milicia and Vladimiro Sassone. The Inheritance Symbolic Computation. 1998.
Anomaly: Ten Years After SAC. Nicosia, Cyprus. March Dave Thomas and Brian Barry. Using Active Objects for
2004. Structuring Service Oriented Architectures:
Mark S. Miller Robust Composition: Towards a Unified Anthropomorphic Programming with Actors Journal of
Approach to Access Control and Concurrency Control Object Technology. July-August 2004.
Doctoral Dissertation. John Hopkins. 2006. Darrell Woelk. Developing InfoSleuth Agents Using
George Milne and Robin Milner. “Concurrent processes Rosette: An Actor Based Language Proceedings of the
and their syntax” JACM. April, 1979. CIKM '95 Workshop on Intelligent Information Agents.
Robert Milne and Christopher Strachey. A Theory of 1995.
Programming Language Semantics Chapman and Hall. Akinori Yonezawa, Ed. ABCL: An Object-Oriented
1976. Concurrent System MIT Press. 1990.
Robin Milner Processes: A Mathematical Model of Aki Yonezawa Specification and Verification Techniques
Computing Agents Proceedings of Bristol Logic for Parallel Programs Based on Message Passing
Colloquium. 1973. Semantics MIT EECS Doctoral Dissertation. December
Robin Milner Elements of interaction: Turing award 1977.
lecture CACM. January 1993. Hadasa Zuckerman and Joshua Lederberg. Postmature
Marvin Minsky (ed.) Semantic Information Processing MIT Scientific Discovery? Nature. December, 1986.
Press. 1968.
Allen Newell and Herbert Simon. The Logic Theory
Machine: A Complex Information Processing System.
Rand Technical Report P-868. June 15, 1956
Carl Petri. Kommunikation mit Automate Ph. D. Thesis.
University of Bonn. 1962.
Gordon Plotkin. A powerdomain construction SIAM
Journal of Computing. September 1976.
George Polya (1957) Mathematical Discovery: On
Understanding, Learning and Teaching Problem
Solving Combined Edition Wiley. 1981.
Karl Popper (1935, 1963) Conjectures and Refutations: The
Growth of Scientific Knowledge Routledge. 2002.
John Reynolds. Definitional interpreters for higher order
programming languages ACM Conference Proceedings.
1972.
Bill Roscoe. The Theory and Practice of Concurrency
Prentice-Hall. Revised 2005.
Dana Scott and Christopher Strachey. Toward a
mathematical semantics for computer languages Oxford
Programming Research Group Technical Monograph.
PRG-6. 1971
Charles Seitz. The Cosmic Cube CACM. Jan. 1985.
Michael Smyth. Power domains Journal of Computer and
System Sciences. 1978.
Guy Steele Jr. Lambda: The Ultimate Declarative MIT AI
Memo 379. November 1976.
Gunther Stent. Prematurity and Uniqueness in Scientific
Discovery Scientific American. December, 1972.

 when assert P, assert Q
when goal Q, goal P
xvii
Appendix: Historical Background 
The Actor model builds on previous models of  when assert (not Q), assert (not P)
nondeterministic computation. Several models of
nondeterministic computation were developed including  when goal (not P), goal (not Q)
the following: Planner was the first programming language based on the
pattern-directed invocation of procedural plans from
Petri nets assertions and goals. It represented a rejection of the
resolution uniform proof procedure paradigm.
Prior to the development of the Actor model, Petri nets
were widely used to model nondeterministic computation.
Smalltalk-72
However, they were widely acknowledged to have an
important limitation: they modeled control flow but not Planner, Simula, Smalltalk-72 [Kay 1975; Ingalls 1983]
data flow. Consequently they were not readily composable and computer networks had previously used message
thereby limiting their modularity. Hewitt pointed out passing. However, they were too complicated to use as the
another difficulty with Petri nets: simultaneous action, i.e., foundation for a mathematical theory of concurrency. Also
the atomic step of computation in Petri nets is a transition they did not address fundamental issues of concurrency.
in which tokens simultaneously disappear from the input
places of a transition and appear in the output places. The Alan Kay was influenced by message passing in the
physical basis of using a primitive with this kind of pattern-directed invocation of Planner in developing
simultaneity seemed questionable to him. Despite these Smalltalk-71. Hewitt was intrigued by Smalltalk-71 but
apparent difficulties, Petri nets continue to be a popular was put off by the complexity of communication that
approach to modeling nondeterminism, and are still the included invocations with many fields including global,
subject of active research. sender, receiver, reply-style, status, reply, operator
selector, etc.
Simula
In November 1972 Kay visited MIT and discussed some of
Simula pioneered using message passing for computation, his ideas for Smalltalk-72 building on the Logo work of
motivated by discrete event simulation applications. These Seymour Papert and the “little person” metaphor of
applications had become large and unmodular in previous computation used for teaching children to program.
simulation languages. At each time step, a large central However, the message passing of Smalltalk-72 was quite
program would have to go through and update the state of complex [Kay 1975]. Code in the language was viewed by
each simulation object that changed depending on the state the interpreter as simply a stream of tokens. As Dan Ingalls
of which ever simulation objects that it interacted with on [1983] later described it:xx
that step. Kristen Nygaard and Ole-Johan Dahl developed The first (token) encountered (in a program) was
the idea (first described in an IFIP workshop in 1967) of looked up in the dynamic context, to determine the
having methods on each object that would update its own receiver of the subsequent message. The name lookup
local state based on messages from other objects. In began with the class dictionary of the current
addition they introduced a class structure for objects with activation. Failing there, it moved to the sender of that
inheritance. Their innovations considerably improved the activation and so on up the sender chain. When a
modularity of programs. Simula used nondeterministic binding was finally found for the token, its value
coroutine control structure in its simulations. became the receiver of a new message, and the
interpreter activated the code for that object's class. xxi
Planner
The two major paradigms for constructing semantic Thus the message passing model in Smalltalk-72 was
software systems were procedural and logical. The closely tied to a particular machine model and
procedural paradigm was epitomized by using Lisp programming language syntax that did not lend itself to
[McCarthy et al. 1962; Minsky, et al. 1968] recursive concurrency. Also, although the system was bootstrapped
procedures operating on list structures. The logical on itself, the language constructs were not formally defined
paradigm was epitomized by uniform resolution theorem as objects that respond to Eval messages (see discussion
provers [Robinson 1965]. below).
Planner [Hewitt 1969] was a kind of hybrid between the
procedural and logical paradigms.xviii An implication of the Arguably, the first concurrent programs were interrupt
form (P implies Q) was procedurally interpreted as handlers. During the course of its normal operation, a
follows:xix computer needed to be able to receive information from

outside (characters from a keyboard, packets from a with input from outside, e.g. keyboard input, disk access,
network, etc.). So when the information arrived, execution network input, etc. So it could take an unbounded time for
of the computer was “interrupted” and special code called a message sent to a computer to be received and in the
an interrupt handler was called to put the information in a meantime the computer could traverse an unbounded
buffer where it could be subsequently retrieved. number of states. Thus the computer may not be in any
defined stable state for an unbounded period of time
In the early 1960s, interrupts began to be used to simulate [Hewitt 2006]. Therefore computers have the property of
the concurrent execution of several programs on a single unbounded nondeterminism. So there is an inconsistency
processor. Having concurrency with shared memory gave between the nondeterministic state model of computation
rise to the problem of concurrency control. Originally, this and the circuit model of arbiters.xxii
problem was conceived as being one of mutual exclusion
on a single computer. Edsger Dijkstra developed Scott and Strachey [1971] proposed to develop a
semaphores and later, [Brinch Hansen 1996; Hoare 1974] mathematical semantics for programming languages based
developed monitors to solve the mutual exclusion problem. on the lambda calculus [Church 1941].xxiii However, the
However, neither of these solutions provided a nondeterministic lambda calculus has bounded
programming language construct that encapsulated access nondeterminism [Plotkin 1976] and is incapable of
to shared resources. This encapsulation was later implementing concurrency.
accomplished by the serializer construct [Hewitt and
Atkinson 1977, 1979; Atkinson 1980]. Actors
The invention of digital computers caused a decisive
The first models of computation (e.g. Turing machines, paradigm shift when the notion of an interrupt was
Post productions, the lambda calculus, etc.) were based on invented so that input that arrived asynchronously
mathematics and made use of a global state to represent a from outside could be incorporated in an ongoing
computational step (later generalized in [McCarthy and
computation. At first concurrency was conceived
Hayes 1969] and [Dijkstra 1976]). Each computational step
was from one global state of the computation to the next using low level machine implementation concepts
global state. The global state approach was continued in like threads, locks, channels, cores, queues, etc.
automata theory for finite state machines and push down
stack machines, including their nondeterministic versions. The Actor Model [Hewitt, Bishop, and Steiger 1973]
Such nondeterministic automata have the property of was based on message passing.xxiv The Actor model
bounded nondeterminism; that is, if a machine always halts has laws that govern privacy and security [Baker and
when started in its initial state, then there is a bound on the Hewitt 1977].xxv The break was decisive because
number of states in which it halts. asynchronous communication cannot be implemented
by Turing machines etc. because the order of arrival
Edsger Dijkstra further developed the nondeterministic of messages cannot be logically inferred. Message
global state approach. Dijkstra's model gave rise to a passing is the foundation of many-core and client-
controversy concerning unbounded nondeterminism.
cloud computing.
Unbounded nondeterminism (also called unbounded
indeterminacy), is a property of concurrency by which the
amount of delay in servicing a request can become Actor Semantics
unbounded as a result of arbitration of contention for Consider the following program written in CSPxxvi [Hoare
shared resources while still guaranteeing that the request 1978]:
will eventually be serviced. The Actor model provides the
guarantee of service. In Dijkstra's model, although there [X :: Z!stop( )
could be an unbounded amount of time between the ||
execution of sequential instructions on a computer, a Y :: guard: boolean; guard := true;
(parallel) program that started out in a well-defined state *[guard  Z!go( ); Z?guard]
could terminate in only a bounded number of states ||
[Dijkstra 1976]. Dijkstra argued that it was impossible to
Z :: n: integer; n:= 0;
implement unbounded nondeterminism.
continue: boolean; continue := true;
*[X?stop( ) continue := false;
[]
However, there is no bound that can be placed on how long Y?go( ) n := n+1; Y!continue
it takes a computational circuit called an arbiter to settle. ]
Arbiters are used in computers to deal with the ]
circumstance that computer clocks operate asynchronously

According to Clinger [1981]:
this program illustrates global nondeterminism, since
the nondeterminism arises from incomplete specification SimpleCounter 
of the timing of signals between the three processes X, Y, serializer
and Z. The repetitive guarded command in the definition
𝐧
of Z has two alternatives: either the stop message is  n is the current count
accepted from X, in which case continue is set to false, 𝐈𝐧𝐭𝐞𝐠𝐞𝐫
or a go message is accepted from Y, in which case n is
incremented and Y is sent the value of continue. If Z implements Counter
ever accepts the stop message from X, then X terminates.  implements the Counterxxviii interface
Accepting the stop causes continue to be set to false, so Again< >
after Y sends its next go message, Y will receive false as 𝒗𝒐𝒊𝒅
the value of its guard and will terminate. When both X when an Again message is received
and Y have terminated, Z terminates because it no longer {future self Again< >,
has live processes providing input.
As the author of CSP points out, therefore, if the
return also become(n=n+1)}
repetitive guarded command in the definition of Z were  send an Again message to
required to be fair, this program would have unbounded  this counter and in parallel return also
nondeterminism: it would be guaranteed to halt but  incrementing the count
there would be no bound on the final value of n.xxvii In Stop< >
actual fact, the repetitive guarded commands of CSP are 𝐈𝐧𝐭𝐞𝐠𝐞𝐫
not required to be fair, and so the program may not halt when a Stop message is received
[Hoare 1978]. This fact may be confirmed by a tedious return n return the count
calculation using the semantics of CSP [Francez, Hoare,
Lehmann, and de Roever 1979] or simply by noting that
By the semantics of the Actor model of computation
the semantics of CSP is based upon a conventional
power domain and thus does not give rise to unbounded [Clinger 1981; Hewitt 2006], the result of evaluating the
nondeterminism. expression UnboundedStart< > is an integer of
unbounded size.
However, the following concurrent program in ActorScript
will return an integer of unbounded size: The model of CSP deliberately had bounded
nondeterminism [Francez, Hoare, Lehmann, and de Roever
Unbounded  1979] whereas the Actor model has unbounded
nondeterminism. Influence by Dijkstra, Hoare had been
behavior convinced that a programming language with unbounded
Start< > nondeterminism could not be implemented. Consequently
𝐈𝐧𝐭𝐞𝐠𝐞𝐫 it was not possible to guarantee that servers implemented
 when a Start message is received using CSP would provide service to multiple clients. xxix
𝐜
let = new SimpleCounter(n=0);
𝐂𝐨𝐮𝐧𝐭𝐞𝐫 In 1975, Irene Greif published the first operational model
let c be a new SimpleCounter with count 0 of Actors in her dissertation. Two years after Greif
{cAgain< >, return cStop< >} published her operational model, Carl Hewitt and Henry
 send an Again message to c and in parallel Baker published the Laws for Actors. Other major
 return the value of milestones include [Clinger 1981] introducing a
denotational semantics based on power domains, and
 sending a Stop message to c
[Agha 1985] which further developed a complementary
transition-based semantic model.
Logic Programmingxxx
Robert Kowalski developed the thesis that “computation
could be subsumed by deduction” [Kowalski 1988a] that
he states was first proposed by Hayes [1973] in the form
“Computation = controlled deduction.” [Kowalski 1979]
This thesis was also implicit in one interpretation of
Cordell Green‟s earlier work [Green 1969]. Kowalski
forcefully stated:

There is only one language suitable for that are guardians of shared resources. Gerry Barber's 1981
representing information -- whether declarative or doctoral dissertation concerned reasoning about change in
procedural -- and that is first-order predicate knowledgeable office systems.
logic. There is only one intelligent way to process
information -- and that is by applying deductive Early Actor Programming languages
inference methods. [Kowalski 1980]
Henry Lieberman, Dan Theriault, et al. developed Act1, an
Actor programming language. Subsequently for his
The gauntlet was officially thrown in The Challenge of master‟s thesis, Dan Theriault developed Act2. These early
Open Systems [Hewitt 1985] to which [Kowalski 1988b] proof of concept languages were rather inefficient and not
replied in Logic-Based Open Systems. This was followed suitable for applications. In his doctoral dissertation, Ken
up with [Hewitt and Agha 1988] in the context of the
Kahn developed Ani, which he used to develop several
Japanese Fifth Generation Project. All of this was against
animations. Bill Kornfeld developed the Ether
Kowalski who stated “Looking back on our early
programming language for the Scientific Community
discoveries, I value most the discovery that computation Metaphor in his doctoral dissertation. William Athas and
could be subsumed by deduction.” [Kowalski 1988a] Nanette Boden [1988] developed Cantor which is an Actor
Kowalski also stated that “computation could be subsumed programming language for scientific computing. Jean-
by deduction” [Kowalski 1988a] Pierre Briot [1988, 1999] developed means to extend
Smalltalk 80 for Actor computations. Darrell Woelk [1995]
According to Hewitt et. al. and contrary to Kowalski and
at MCC developed an Actor programming language for
Hayes, computation in general cannot be subsumed by
InfoSleuth agents in Rosette.
deduction and contrary to the quotation (above) attributed
to Hayes computation in general is not controlled Hewitt, Attardi, and Lieberman [1979] developed
deduction. Hewitt and Agha [1991] and other published proposals for delegation in message passing. This gave rise
work argued that mathematical models of concurrency did
to the so-called inheritance anomaly controversy in object-
not determine particular concurrent computations because
oriented concurrent programming languages [Satoshi
they make use of arbitration for determining which
Matsuoka and Aki Yonezawa 1993, Giuseppe Milicia and
message is next in the arrival order when multiple Vladimiro Sassone 2004].
messages concurrently. For example Arbiters can be used
in the implementation of the arrival order. Since arrival
orders are in general indeterminate, they cannot be Hairy Control Structure Redux
deduced from prior information by mathematical logic Scott and Strachey [1971] furthered the research program
alone. Therefore mathematical logic cannot implement of attempting to reduce all computation to the lambda
concurrent computation in open systems. calculus culminating in Milne and Strachey [1976].
In concrete terms, typically we cannot observe the details McDermott and Sussman in [1972] developed the Lisp-
by which the arrival order of messages determined. based language Conniver based on “hairy control
Attempting to do so affects the results and can even push structure” (first introduced in [Landin 1965]) that could
the indeterminacy elsewhere. Instead of observing the implement non-chronological backtracking that was more
internals of arbitration processes, we await outcomes. The general than the chronological backtracking in Planner.
reason that we await outcomes is that we have no Hewitt and others were skeptical of hairy control structure.
alternative because of indeterminacy. Pat Hayes [1974] remarked:
Their [Sussman and McDermott] solution, to give the
Reasoning about Actors user access to the implementation primitives of
Planner, is however, something of a retrograde step
The principle of Actor induction is:
(what are Conniver's semantics?).
1. Suppose that an Actor x has property P when it is
created
In the 1960‟s at the MIT AI Lab a remarkable culture grew
2. Further suppose that if x has property P when it
up around “hacking” that concentrated on remarkable feats
processes a message, then it has property P when
of programming.xxxi Growing out of this tradition, Gerry
it processes the next message.
Sussman and Guy Steele decided to try to understand
3. Then x always has the property P.
Actors by reducing them to machine code that they could
understand and so developed a “Lisp-like language,
In his doctoral dissertation, Aki Yonezawa developed
Scheme, based on the lambda calculus, but extended for
further techniques for proving properties of Actor systems
side effects, multiprocessing, and process
including those that make use of migration. Russ Atkinson
synchronization.” [Sussman and Steele 1975]
developed techniques for proving properties of Serializers
Unfortunately, their reductionist approach included

primitives like START!PROCESS, STOP!PROCESS and results in the creation of a new future (see meta interpreter
EVALUATE!UNINTERRUPTIBLEY that had the following in this paper).
explanation:xxxii
This is the synchronization primitive. It evaluates an Garbage Collection
expression uninterruptedly; i.e. no other process may
Garbage collection (the automatic reclamation of unused
run until the expression has returned a value.
storage) was an important theme in the development of the
Of course, the above reductionist approach is very
Actor model.
unsatisfactory because it missed a crucial aspect of the
Actor model: the arrival ordering of messages. In his doctoral dissertation, Peter Bishop developed an
algorithm for garbage collection in distributed systems.
On the basis of their experience, Sussman and Steele
Each system kept lists of links of pointers to and from
developed the general thesis that Actors were merely the
other systems. Cyclic structures were collected by
lambda calculus in disguise. Steele [1976] in the section
incrementally migrating Actors (objects) onto other
“Actors ≡ Closures (mod Syntax)” disagreed with Hewitt systems which had their addresses until a cyclic structure
who had “expressed doubt as to whether these underlying was entirely contained in a single system where the
continuations can themselves be expressed as lambda garbage collector could recover the storage.
expressions.” However, Actor customers cannot be
expressed as lambda expressions because doing so would
Henry Baker developed an algorithm for real-time garbage
preclude being able to enforce the Actor requirement that a
collection is his doctoral dissertation. The fundamental
customer will process at most one response (i.e. exception
idea was to interleave collection activity with construction
or value return). Also implementing customers as lambda activity so that there would not have to be long pauses
expressions can leave customers stranded (see while collection takes place.
implementations of continuations in ActorScript below).
Lieberman and Hewitt [1983] developed a real time
Pursuing Sussman‟s previous work on hairy control
garbage collection based on the lifetimes of Actors
structurexxxiii, Sussman and Steele [1975] noticed some (Objects). The fundamental idea was to allocate Actors
similarities between Actor customers and continuations
(objects) in generations so that only the latest generations
that had been introduced by [Reynolds 1972] using a
would have to be examined during a garbage collection.
primitive called escape. They called their variant of
escape by the name “call with current continuation.” xxxiv
Unfortunately, general use of escape is not compatible Cosmic Cube
with usual hardware stack disciple introducing The Cosmic Cube was developed by Chuck Seitz et al. at
considerable operational inefficiency. Also, using escape Caltech providing architectural support for Actor systems.
can leave customers stranded.xxxv Consequently, use of A significant difference between the Cosmic Cube and
escape is generally avoided these days and exceptionsxxxvi most other parallel processors is that this multiple
are used instead so that clean up can be performed.xxxvii instruction multiple-data machine used message passing
instead of shared variables for communication between
In summary, Sussman and Steele [1975] mistakenly concurrent processes. This computational model was
concluded “we discovered that the „Actors' and the lambda reflected in the hardware structure and operating system,
expressions were identical in implementation.”xxxviii The and also the explicit message passing communication seen
actual situation is that the lambda calculus is capable of by the programmer.
expressing some kinds of sequential and parallel control
structures but, in general, not the concurrency expressed in J–Machine
the Actor model.xxxix On the other hand, the Actor model is
The J–Machine was developed by Bill Dally et al. at MIT
capable of expressing everything in the lambda calculus
providing architectural support suitable for Actors. This
and more [Hewitt 2008f].
included the following:
 Asynchronous messaging
Promises  A uniform space of Actor addresses to which
Promises [Liskov and Shrira 1988] are derived from messages could be sent concurrently regardless of
futures [Baker and Hewitt 1977]. According to [Miller whether the recipient Actor was local or nonlocal
2006]: “Messages sent to [a] promise cannot be delivered  A form of Actor pipelining
until the promise is resolved, so they are buffered in FIFO Concurrent Smalltalk (which can be modeled using Actors)
order within the promise.” Derivative futures are different was developed to program the J Machine.
from promises in that a message sent to a derivative future

Pi-calculus  output: c<m>.P is a process that puts a message
Robin Milner's initial published work on concurrency m on communication channel c before proceeding
[Milner 1973] was notable in that it positions mathematical as P. In ActorScript, this can be modeled as
semantics of communicating processes as a framework to follows:
understand a variety of interaction agents including the {cPut<m>, P}
computer's interaction with memory. The framework of
modeling was based on Scott's model of domains and as The rest of the Pi-calculus can be modeled using a two-
such was not based on sequential processes. His work phase commit protocol [Knabe 1992].
differed from the Actor model in the following ways:
 There are a fixed number of processes as opposed to Was the Actor model premature?
the Actor model which allows the number of Actors The history of the Actor model raises the question of
to vary dynamically whether it was premature.
 The only quantities that can be passed in messages
are integers and strings as opposed to the Actor Original definition of prematurity
model which allows the addresses of Actors to be
passed in messages As originally defined by Gunther Stent [1972], “A
 The processes have a fixed topology as opposed to discovery is premature if its implications cannot be
the Actor model which allows varying topology connected by a series of simple logical steps to
contemporary canonical or generally accepted knowledge.”
 Communication is synchronous as opposed to the
Ilana Lövy 2002 glossed the phrase "series of simple
Actor model in which an unbounded time can elapse
logical steps" in Stent's definition as referring to the “target
between sending and receiving a message.
community's ways of asking relevant questions, of
 The semantics provided bounded nondeterminism
producing experimental results, and of examining new
unlike the Actor model with unbounded
evidence.” Michael Ghiselin [2002] argued that if a
nondeterminism. However, with bounded
“minority of scientists accept a discovery, or even pay
nondeterminism is impossible for a server to
serious attention to it, then the discovery is not altogether
guarantee service to its clients, i.e., a client might
premature in the Stentian sense.” In accord with Ghiselin's
starve.
argument, the Actor model was not premature. Indeed it
enjoyed initial popularity and for a couple of decades
Building on the Actor model, Milner [1993] removed some underwent steady development.
of these restrictions in his work on the Pi calculus:
Now, the pure lambda-calculus is built with just two
However, Stent in his original article also referred to a
kinds of thing: terms and variables. Can we achieve the
development as premature such that when it occurred
same economy for a process calculus? Carl Hewitt, with
contemporaries did not seem to be able to do much with or
his Actors model, responded to this challenge long ago;
build on. This is what happened after a while with the
he declared that a value, an operator on values, and a
Actor model. The reasons were twofold:
process should all be the same kind of thing: an Actor.
1. For over 30 years after the first publication of the
This goal impressed me, because it implies the
Actor model, widely deployed computer
homogeneity and completeness of expression ... But it
architectures developed in the direction of making
was long before I could see how to attain the goal in
a single sequential thread of execution run faster.
terms of an algebraic calculus...
2. For over 25 years after the first publication, there
So, in the spirit of Hewitt, our first step is to demand
was no agreed standard by which software could
that all things denoted by terms or accessed by names--
communicate high level data structures across
values, registers, operators, processes, objects--are all
organizational boundaries.
of the same kind of thing; they should all be processes.
Thereafter we regard access-by-name as the raw
material of computation... Before its time?
According to Elihu M. Gerson [2002], phenomena that
Communication in the pi-calculus takes the following lead people to talk about discoveries being before their
form: time can be analyzed as follows:
 input: c(x).P is a process that gets a message from We can see the phenomenon of 'before its time' as
a communication channel named c before composed of two separate steps. The first takes place
proceeding as P, binding the message received to when a new discovery does not get tied to the
the identifier x. In ActorScript, this can be conventional knowledge of its day and remains
modeled as follows: unconnected in the literature. The second step occurs
let x=cGet<>, P when new events lead to the 'rediscovery' of the

unconnected results in a changed context that enables End Notes
or even facilitates its connection to the conventional
knowledge of the rediscovering context. i
In part, this section extends some material that was
submitted to Wikipedia.
Now both of the above circumstances that held back the
Actor model have changed with the development of ii
E.g. processes in Erlang [Armstrong 2007] and vats in the
(1) many-core computer architectures a object-capability model [Miller 2006].
(2) client-cloud computing
By the criteria of Gerson, the Actor model might be iii
ORGs are a further development of “Anthropomorphic
described by some as before its time. Programming” [Booth and Gentleman 1984]:
Alan Karp has pointed out that experience with MIMD
According to Hadasa Zuckerman and Joshua Lederberg architectures invites an analogy with human
[1986], premature discoveries are those that were made but organizations. For a very small number of processors
neglected. By their criteria it remains to be seen whether or (people) detailed interactions can be maintained
not the Actor model was premature. without a manager; with a modest number of
processors (people) the interaction patterns can be
Gerson 2002 argued, handled by simple structuring techniques that
But histories and sociological studies repeatedly show decompose the problem into distinct tasks with well-
that we do not have a discovery until the scientific defined areas of responsibility; with a very large
community accepts it as such and stops debating about number of processors (people) the interaction becomes
it. Until then the proposed solution is in an intermediate so complicated that more rigid organizations imposing
state.” a high degree of regularity seems to be required. We
By his argument, the Actor model is a discovery but since suggest that these three levels may be understood best
its practical importance is not yet accepted by the through the metaphors of anthropomorphic
community, its practical importance is not yet a discovery. programming.
Also see [Thomas and Barry 2004].
iv
For background information on ORGs see [Bowker, Star,
Turner, and Gasser 1977; Singh and Huhns 2005; Horling
and Lesser 2005].
ORGs are a successor to the earlier Mental Agent
paradigm where a Mental Agent is defined behaviorally as
cognitively operating like a human. See further discussion
in [Hewitt 2008g].
v
Doing large-scale computations in the cloud will in
general require Service Level Agreements from neutral
cloud utilities that they will not spy on the computations of
the (perhaps anonymous) clients. Also clients can take
various technical means to make spying by utilities more
difficult.
vi
Many others subsequently further developed this style of
meta-circular interpreter.
vii
Just because packagers can print as XML strings does
not meant that they are equivalent to XML strings.
Packagers are opaque binary structures that cannot be
forged when signed and are secret when transmitted on the
wire are protected by encryption. For example, the
implementation of futures (below) depends on this kind of
privacy and security for the correctness of the
implementation.

viii xx
Note that Kurt must be quoted in the ActorScript expression Subsequent versions of the Smalltalk language largely
PersonName<First<“Kurt”> Last<“Gödel”> > in order to followed the path of using the virtual methods of Simula in
evaluate to the string . “Kurt”. the message passing structure of programs. However
Smalltalk-72 made primitives such as integers, floating
ix
This expression could print as follows: point numbers, etc. into objects. The authors of Simula had
{"firstName": "John", considered making such primitives into objects but
"lastName": "Smith", refrained largely for efficiency reasons. Java at first used
"address": {"streetAddress": "21 2nd Street", the expedient of having both primitive and object versions
"city": "New York", of integers, floating point numbers, etc. The C#
"state": "NY",
"postalCode": 10021},
programming language (and later versions of Java, starting
"phoneNumbers": ["555-1234", "555-4567"]} with Java 1.5) adopted the more elegant solution of using
boxing and unboxing, a variant of which had been used
x
Also the meta-circular programs can be extensively earlier in some Lisp implementations.
optimized by using the interfaces and implementation xxi
types. According to the Smalltalk-72 Instruction Manual
[Goldberg and Kay 1976]:
xi
The interfaces in ActorScript are related to the protocols There is not one global message to which all message
originally developed for Objective C at NeXT that also "fetches" (use of the Smalltalk symbols eyeball,  ; colon,
influenced the development of interfaces in Java and :, and open colon, 𝑜𝑜 ) refer; rather, messages form a
subsequently in C#: hierarchy which we explain in the following way--
Modula-3 also had interfaces. [Cardelli et. al. 1989]. suppose I just received a message; I read part of it and
decide I should send my friend a message; I wait until my
xii
ActorScript interfaces can specify additional optional friend reads his message (the one I sent him, not the one I
information as well received); when he finishes reading his message, I return
to reading my message. I can choose to let my friend read
xiii
This expression is equivalent to the rest of my message, but then I cannot get the message
Sequence<expression1, …, expressionn > Also ?* means back to read it myself (note, however, that this can be
the same as [?*]. done using the Smalltalk object apply which will be
discussed later). I can also choose to include permission
xiv
An attempt to send another response to a customer that in my message to my friend to ask me to fetch some
has already received one will throw an exception. information from my message and to give that in
information to him (accomplished by including: or 𝑜𝑜 in
xv
Of course, more sophisticated processing that first-in the message to the friend). However, anything my friend
first-out can be implemented using the customers in fetches, I can no longer have. In other words,
communications. However, discussion of this topic is 1) An object (let's call it the CALLER) can send a
beyond the scope of this paper. message to another object (the RECEIVER) by
simply mentioning the RECEIVER's name followed
xvi
Relay is used to prevent a security attack in which an by the message.
attacker attempts to fake an outcome. 2) The action of message sending forms a stack of
messages; the last message sent is put on the top.
xvii
In part, this section extends some material that was 3) Each attempt to receive information typically means
submitted to Wikipedia. looking at the message on the top of the stack.
xviii
4) The RECEIVER uses the eyeball, , the colon, :, and
The development of Planner was inspired by the work the open colon, 𝑜𝑜 , to receive information from the
of Karl Popper [1935, 1963], Frederic Fitch [1952], message at the top of the stack.
George Polya [1954], Allen Newell and Herbert Simon 5) When the RECEIVER completes his actions, the
[1956], John McCarthy [1958, et. al. 1962], and Marvin message at the top of the stack is removed and the
Minsky [1968]. ability to send and receive messages returns to the
xix
CALLER. The RECEIVER may return a value to be
This turned out later to have a surprising connection used by the CALLER.
with Direct Logic. See the Two-Way Deduction Theorem 6) This sequence of sending and receiving messages,
below. viewed here as a process of stacking messages,
means that each message on the stack has a
CALLER (message sender) and RECEIVER

(message receiver). Each time the RECEIVER is calculus, the interpreter for the programming language
finished, his message is removed from the stack and Lisp made use of a data structure called an environment so
the CALLER becomes the current RECEIVER. The that the values of parameters did not have to be substituted
now current RECEIVER can continue reading any into the body of an invoked lambda expression. This
information remaining in his message. allowed for sharing of the effects of updating shared data
7) Initially, the RECEIVER is the first object in the structures but did not provide for concurrency.
message typed by the programmer, who is the
xxiv
CALLER. Process calculi (e.g. [Milner 1993; Cardelli and Gordon
8) If the RECEIVER's message contains an eyeball,  ; 1998]) are closely related to the Actor model. There are
colon, :, or open colon, 𝑜𝑜 , he can obtain further many similarities between the two approaches, but also
information from the CALLER's message. Any several differences (some philosophical, some technical):
information successfully obtained by the  There is only one Actor model (although it has
RECEIVER is no longer available to the CALLER. numerous formal systems for design, analysis,
9) By calling on the object apply, the CALLER can verification, modeling, etc.); there are numerous
give the RECEIVER the right to see all of the process calculi, developed for reasoning about a
CALLER's remaining message. The CALLER can variety of different kinds of concurrent systems at
no longer get information that is read by the
RECEIVER; he can, however, read anything that various levels of detail (including calculi that
remains after the RECEIVER completes its actions. incorporate time, stochastic transitions, or constructs
10) There are two further special Smalltalk symbols specific to application areas such as security
useful in sending and receiving messages. One is the analysis).
keyhole, , that lets the RECEIVER “peek” at the  The Actor model was inspired by the laws of
message. It is the same as the 𝑜𝑜 except it does not physics and depends on them for its fundamental
remove the information from the message. The
axioms, i.e. physical laws (see Actor model theory);
second symbol is the hash mark, #, placed in the
message in order to send a reference to the next the process calculi were originally inspired by
token rather than the token itself. algebra [Milner 1993].
 Processes in the process calculi are anonymous, and
xxii
Of course the same limitation applies to the Abstract communicate by sending messages either through
State Machine (ASM) model [Blass, Gurevich, named channels (synchronous or asynchronous), or
Rosenzweig, and Rossman 2007a, 2007b; Glausch and via ambients (which can also be used to model
Reisig 2006]. In the presence of arbiters, the global states
channel-like communications [Cardelli and Gordon
in ASM are mythical.
1998]). In contrast, Actors in the Actor model
xxiii possess an identity, and communicate by sending
The lambda calculus can be viewed as the earliest
message passing programming language [Hewitt, Bishop, messages to the mailing addresses of other Actors
and Steiger 1973]. For example the lambda expression (this style of communication can also be used to
below implements a tree data structure when supplied with model channel-like communications).
parameters for a leftSubTree and rightSubTree. When Process calculi can be modeled in the Actor model using a
such a tree is given a parameter message "getLeft", it two-phase commit protocol [Knabe 1992].
returns leftSubTree and likewise when given the message
"getRight" it returns rightSubTree: xxv
These laws can be enforced by a proposed extension of
λ(leftSubTree, rightSubTree)
the X86 architecture that will support the following
λ(message)
operating environments:
if (message == "getLeft")
 CLR and extensions (Microsoft)
then leftSubTree
else if (message == "getRight")  JVM (Sun, IBM, Oracle, SAP)
then rightSubTree  Dalvik (Google)
However, the semantics of the lambda calculus were Many-core architecture has made the above extension
expressed using variable substitution in which the values of necessary in order to provide the following:
parameters were substituted into the body of an invoked  concurrent nonstop automatic storage reclamation
lambda expression. The substitution model is unsuitable (garbage collection) and relocation to improve
for concurrency because it does not allow the capability of
efficiency,
sharing of changing resources. Inspired by the lambda
 prevention of memory corruption that otherwise

xxvii
results from programming languages like C and C++ Of course, n would not survive the termination of Z
using thousands of threads in a process, and so the value cannot actually be exhibited after
nonstop migration of ORGs (while they are in operation) termination! In the ActorScript program below, the
within a computer and between distributed computers unbounded count is sent to the customer of the Start[ ]
message so that it appears externally.
xxvi
In summary, CSP differed from the Actor model in the xxviii
The Counter interface can be defined as follows:
following respects: Counter 
 The concurrency primitives of CSP were input,
interface
output, guarded commands, and parallel  Counter is defined to be an interface
composition whereas the Actor model is based on
Again< >
asynchronous one-way messaging. 𝒗𝒐𝒊𝒅
 The fundamental unit of execution was a sequential  an Again<> message returns Void
process in contrast to the Actor model in which Stop< >
execution was fundamentally concurrent. Sequential  a Stop<> message returns an Integer
execution is problematical because multi-processor
computers are inherently concurrent. xxix
Hoare [1985] developed a revised versions of CSP with
 The processes had a fixed topology of unbounded nondeterminism [Roscoe 2005].
communication whereas Actors had a dynamically
changing topology of communications. Having a xxx
See [Hewitt 2008c] for a more complete history.
fixed topology is problematical because it precludes
the ability to dynamically adjust to changing xxxi
Notable members of this community included Bill
conditions. Gosper, Richard Greenblatt, Jack Holloway, Tom Knight,
 The processes were hierarchically structured using Stuart Nelson, Peter Samson, Richard Stallman, etc.. See
parallel composition whereas Actors allowed the [Levy 1984].
creation of non-hierarchical execution using futures
[Baker and Hewitt 1977]. Hierarchical parallel xxxii
For semantics, Sussman and Steele [1975] proposed an
composition is problematical because it precludes interpreter for a time-sliced processor.
the ability to create a process that outlives its
creator. Also message passing is the fundamental xxxiii
McDermott, and Sussman in [1972] developed the
mechanism for generating parallelism in the Actor Lisp-based language Conniver based on "hairy control
model; sending more messages generates the structure" that could implement non-chronological
possibility of more parallelism. backtracking that was more general than the chronological
 Communication was synchronous whereas Actor backtracking in Planner. Hewitt and others were skeptical
communication was asynchronous. Synchronous of hairy control structure. Pat Hayes remarked:
communication is problematical because the Their [Sussman and McDermott] solution, to give the
interacting processes might be far apart. user access to the implementation primitives of
 Communication was between processes whereas in Planner, is however, something of a retrograde step
the Actor model communications are one-way to (what are Conniver's semantics?). [Hayes 1974]
Actors. Synchronous communication between
processes is problematical by requiring a process to
wait on multiple processes.
 Data structures consisted of numbers, strings, and
arrays whereas in the Actor model data structures
were Actors. Restricting data structures to numbers,
strings, and arrays is problematical because it
prohibits programmable data structures.
 Messages contain only numbers and strings whereas
in the Actor model messages could include the
addresses of Actors. Not allowing addresses in
messages is problematical because it precludes
flexibility in communication because there is no
way to supply another process with the ability to
communicate with an already known process.

xxxiv xxxvii
A restricted form of Reynold‟s escape and Scheme‟s Hewitt [1976, 1977] concluded:
call with current continuation primitive can be defined as One of the most important results that has emerged
follows in ActorScript: from the development of Actor semantics has been the
further development of techniques to semantically
escape identifier in body  analyze or synthesize control structures as patterns of
passing messages. As a result of this work, we have
behavior found that we can do without the paraphernalia of
implements Expression "hairy control structure." (emphasis in original
𝐜𝐮𝐬𝐭
Request<Eval<e> > 
𝐂𝐮𝐬𝐭𝐨𝐦𝐞𝐫 xxxviii
This error was partially acknowledged in some of
return their subsequent work.
body 
xxxix
Eval<ebind<identifier, For example, modeling customers as continuation
𝐜𝐨𝐧𝐂𝐮𝐬𝐭 functions led to the hanging customer issue.
(Request<[v] >
 the return value v has been
 received as an argument to the
 continuation
{cust Returned<v>,
no response )>>
Note that the continuation customer conCust is most likely

stranded. This is an important reason that customers are not
lambda expressions contra [Steele 1976].
call with current continuation expression 

behavior
𝐜𝐮𝐬𝐭
Request<Eval<e> > 
return
(expression Eval<e>)
𝐜𝐨𝐧𝐂𝐮𝐬𝐭
(Request<[v] >
 the return value v has been
 received as an argument to the
 continuation
{cust Returned<v>,
no response })
However, customers differ from continuations because

sending more than one response to a customer causes an
exception to be thrown.
Continuations are closely related to Landin‟s J operator.
See Thielecke [1998] for the relationship between the J
operator and continuations.
xxxv
See implementations of continuations in ActorScript
above.
xxxvi
missing from Scheme

Actor Script TM

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Actor Script TM

Uploaded by

Copyright:

Available Formats

Published in ArXiv http://arxiv.org/abs/0907.3330 http://ActorScript.carlhewitt.

Contents An implementation of Futures .................................. 19

December 14, 2009 Page 1 of 42

December 14, 2009 Page 2 of 42

December 14, 2009 Page 3 of 42

December 14, 2009 Page 4 of 42

ActorScript is a general purpose programming language (Eval expression environment) 

December 14, 2009 Page 5 of 42

XML Attributes are allowed so that the expression

In this paper, the dialect of ActorScript used is quite

December 14, 2009 Page 6 of 42

procedure (expression1 …expressionn)

Functions are implemented as unserialized Actors. For

December 14, 2009 Page 7 of 42

Control expressions Sequence construction can be performed in the following

December 14, 2009 Page 8 of 42

December 14, 2009 Page 9 of 42

December 14, 2009 Page 10 of 42

Customers  is defined in terms of 

A Performative is one of the following:

December 14, 2009 Page 11 of 42

procedure(expression1 … expressionn) catch expressions are a standard programming

Communications are sent using ⇚ and received using

December 14, 2009 Page 12 of 42

 Account is defined Cellt 

 SimpleAccount is defined SimpleCellt 

return also become(balance=balance + delta) return also become (contents=nextContents)

The reason that serializer goes beyond the capabilities of

December 14, 2009 Page 13 of 42

A serializer binds the values of the initial values its

Note: in practice, serializers are typically

When a serializer construct receives an Eval message, it

December 14, 2009 Page 14 of 42

A serializer s (conceptually) processes throw exception

December 14, 2009 Page 15 of 42

December 14, 2009 Page 16 of 42

December 14, 2009 Page 17 of 42

December 14, 2009 Page 18 of 42

December 14, 2009 Page 19 of 42

December 14, 2009 Page 20 of 42

December 14, 2009 Page 21 of 42

December 14, 2009 Page 22 of 42

CutOff Sponsors can be used in the implementation of compound expressions as follows:

December 14, 2009 Page 23 of 42

December 14, 2009 Page 24 of 42

December 14, 2009 Page 25 of 42

December 14, 2009 Page 26 of 42

December 14, 2009 Page 27 of 42

December 14, 2009 Page 28 of 42

December 14, 2009 Page 29 of 42

December 14, 2009 Page 30 of 42

December 14, 2009 Page 31 of 42

December 14, 2009 Page 32 of 42

December 14, 2009 Page 33 of 42

December 14, 2009 Page 34 of 42

December 14, 2009 Page 35 of 42

December 14, 2009 Page 36 of 42

December 14, 2009 Page 37 of 42

December 14, 2009 Page 38 of 42

December 14, 2009 Page 39 of 42

December 14, 2009 Page 40 of 42

December 14, 2009 Page 41 of 42

Note that the continuation customer conCust is most likely