ERLANG - AN EXPERIMENTAL TELEPHONY PROGRAMMING LANGUAGE

J. L. Armstrong and S.R.Virding

Computer Science Laboratory, Ellemtel Utvecklings AB

ABSTRACT small independent agents).

We present an experimental programming language
called Erlang which is suitable for programming telephony 1.5. Functional Notation
applications. We discuss some of the requirements for such Erlang looks like a single assignment functional
a language and introduce the language by a series of simple language. There is a subtle difference between Erlang and a
examples which show how both sequential and concurrent strict functional language. Erlang was designed as a
activities can be programmed. We discuss the error recovery language for controlling real time applications where the
mechanism used in Erlang together with the performance control of hardware and strict sequencing of events is very
characteristics of the current implementation. important. In a pure functional language, calling the same
function twice with the same arguments is guaranteed to
1. INTRODUCTION produce the same result. However, in our language, where a
function call may result in a hardware action we cannot
Erlang is a programming language designed for pro-
ensure that the hardware will always produce the same
totyping concurrent real-time distributed applications. It
result. Erlang can be viewed as a strict functional language
grew out of a series of experiments [1,2,3] aimed at creating
as regards computational functions (i.e. those not dependent
a language suitable for programming large scale telephony
upon interaction with the real world for their success) but as
applications. Some of the main characteristics of the
a conventional imperative language as regards for sequenc-
language are as follows:
ing hardware events.
1.1. Robustness
In programming large systems many small program- 1.6. Concurrent
ming errors will be made - we view this as inevitable. For- Erlang applications are built from a large number of
mal systems and exhaustive test procedures are currently not parallel processes. We take the view that the degree of con-
capable of ensuring fault free software for systems of the currency in the application should exactly match the degree
size and complexity of modern telecomms applications. of concurrency in the software structure of the program con-
Given that errors will be made, we are interested in the trolling the application. Programming in an unconstrained
problem of detecting and handling those errors in such a parallel language (where every statement in the language
manner that the system as a whole exhibits satisfactory represents a parallel activity) is difficult and error prone.
behaviour in the presence of errors. Within any individual process we describe sequential
behaviour, but allow any number of such sequential
1.2. Real Time processes to execute concurrently. The only method of syn-
We will be concerned with real time applications. chronising processes or exchanging data between processes
Response times are critical. In many circumstances a partic- is by message passing.
ular operation must be performed within a certain time.
Erlang has mechanisms for expressing real time dependen- 1.7. Modular
cies. Erlang has an in-built module system to make it
easier to construct large systems.
1.3. Distributed 2. SIMPLE EXAMPLES
The kinds of application which we are interested in
Erlang programs are constructed from a large number
are essentially distributed. Such systems are built from a
of small functions.
variable number of communicating nodes. Each node
operates autonomously and there is no central or master Rather than give a formal definition of the Erlang
node in the system. Nodes communicate with other nodes language and its semantics we show some of the language
using some form of underlying transport medium. There is features by example. The syntax of Erlang data structures
only a weak coupling between the actual transport system and variables are similar to those used in Prolog [4].
and the distributed Erlang system. Programs written in We start with the factorial function, this is built from
Erlang can easily be ported from a uni-processor implemen- two Erlang equations:
tation to a multi-processor or multi-node implementation
with minimal code changes. factorial(0) ->
ˆ1.
factorial(N) e N > 0 ->
1.4. Fine Grain N1 = N - 1,
Erlang provides fine grain computational processes. F1 = factorial(N1),
By fine grain we mean that the computational effort required N * F1.
to create or destroy a parallel activity in Erlang is small. The
The general equation syntax has the form:
granularity of computation has an important influence on
how we program. In general fine grain computations are Head e Guard ->
preferable to heavy weight processes for telephony applica- Body.
tions (since the natural way of programming a telephony Function evaluation proceeds by a form of pattern directed
application is as if it were composed of a large number of function evocation. When a function is called, the system
searches for an appropriate equation whose Head matches 1) nil is a struct
the function call. Any variables occurring in the head are 2) subscriber(Who) is a struct
bound to the values supplied in the call. The Guard is then 3) {S1,S2,..S10} is a struct iff
evaluated. If the head matches and the condition implied by S1..S10 are all structs
the guard is true then the system commits and the Body of The object {S1,S2,...S10} is a 10 argument tuple where each
the equation is evaluated. Equations are matched sequen- argument represents an action to be taken if a particular digit
tially in the order they appear on the page until an appropri- is dialled.
ate match is found. It is an error for no equation to match.
If we were to analyse the number sequence [2,1,4,5]
Body evaluation is sequential. The return value of the we would first look at the 3rd argument in the tuple (The
function is the result of evaluating the last statment in the subscriber can dial a digit from 0 to 9, these are represented
function body. A statment of the form Lhs = Rhs occurring by arguments 1 to 10 of the tuple), the third argument would
in the body of a function causes Rhs to be evaluated and the itself by a tuple - we would then look at the 2nd argument
result to be bound to Lhs. in the sub-tree etc.
Lists are written as in Prolog. Thus, for example, a Eventually we should arrive at a terminal node in the
function which reverses the order of elements in a list could Struct which is either nil representing an invalid number, or
be written: subscriber(Who) representing a valid user number.
rev(X) -> rev(X, []). In our example we used two auxiliary functions.
index which is defined thus:
rev([], L) ->
ˆL. index(N) ->
rev([HeT], L) -> N + 1.
rev(T, [HeL]). and the built in function getiarg(N,Struct) which fetches the
N’th argument from Struct. So for example: getiarg(3,
So, for example: foo(a,b,c,d,e)) evaluates to c.
rev([a,b,c,d]) The non recursive equations in both lookup and
evaluates to [d,c,b,a]. lookup1 represent boundary conditions, i.e. analysing a
Note that the notation ˆX denotes a return value and is sequence in an empty tree always gives the result invalid,
short for quote(X), where the function quote merely returns analysing an empty sequence always requires the user to
its unevaluated argument. supply more digits.

The previous examples have shown how functions The 3rd equations in both lookup and lookup1
can be defined using sets of recursion equations. This for- specifies the recursive tree walking case where we succes-
malism, while simple, has considerable power. We can show sively follow the branches of the tree, which branch depend-
some of the expressive power of Erlang by examining a ing upon the next digit in the sequence.
simplified telephony example. Manipulation of a 10-way tree shows some of the
The example is a dialled number analyser. We define power of Erlang for a typical telephony programming
a function lookup(Seq,Struct) which analyses some number problem. Tree insertion is equally simple and is left as an
sequence Seq to see if it represents a valid subscriber exercise for the reader.
number. lookup can be defined as follows: 3. EXAMPLES WITH COMMUNICATION
/* Erlang has primitives for creating a parallel process
* lookup(Seq, Struct) returns (spawn), and for sending and receiving messages (send and
* subscriber(Who) if a valid sequence receive). To illustrate this we take the example of a simple
* getimoreidigits if an ambiguous sequence process that could be created to count charging pulses in a
* invalid if an invalid sequence telephony metering system.
*/ Firstly a process that records debiting pulses.
lookup(Seq, nil) -> -module(counter).
ˆinvalid. -export([start/2]).
lookup([], Struct) ->
ˆgetimoreidigits. start(Sys, Proc) ->
lookup([DigiteMoreidigits], Struct) -> counter(Sys, Proc, 0).
Arg = index(Digit),
X = getiarg(Arg, Stuct), counter(Sys, Proc, Tot) ->
lookup1(X, Moreidigits). receive {
Proc ? bump =>
lookup1(nil, i) -> Tot1 = Tot + 1,
ˆinvalid. counter(Sys, Proc, Tot1);
lookup1(subscriber(Who), i) -> Sys ? report =>
ˆsubscriber(Who). Sys ! Tot,
lookup1(Struct, Moreidigits) -> counter(Sys, Proc, Tot);
lookup(Moreidigits, Struct). Sys ? reset =>
counter(Sys, Proc, 0).
How does this work? Struct is a data structure defined
recursively as follows: The function start is evaluated to start a counter process.
The counter process receives either a bump message from
the process Proc or one of the messages report or reset from
the process Sys. ringingib(A, B) ->
Note that in this example we have included module receive {
declarations. The module declaration in the example causes B ? offihook =>
the function start to be exported from the module, whereas B ! stopiring,
the function counter is purely local to the module. Exported A ! answered,
functions are the only functions which can be accessed from conversationib(A, B);
outside the module. A ? terminate =>
B ! stopiring,
A set of such a counter process could be started as idle(B)
follows: }.
-module(sysistart).
-export([init/2]). The A side of the call evaluates the function
ringingia, the B side ringingib . From the A sides point of
init(Sys,0). view three things can happen. The A side can stop the call
init(Sys,Max) -> attempt by going on hook (the message onihook is received
Id = spawn(lineihandler:start(port(Max))), from the process A), the B partner can answer (the message
spawn(counter:start(Sys, Id)), answered is received from the process B) or a timeout can
Max1 = Max - 1, occur (ie. after 10 seconds the event timeout occurs).
init(Sys, Max1). The Erlang syntax used to express this is:
The function sysistart:init(Sys, Max) when evaluated spawns receive 10 {
Max line handler processes and connects to each line handler A ? onihook =>
process a process to count the number of charging pulses ...
sent by the line handler process. B ? answered =>
Note that inter-module references require fully ...
qualified names - thus we refer to counter:start within the timeout =>
module sysistart but simply start within the module counter. ...
}.
A flexible message passing and process spawning
mechanism provides a convenient framework in which sim- where ... represents the code to be executed if the
ple fragments of a telephony program can be expressed. For condition is true.
example we can illustrates part of the code for a conven- If an onihook message is received the ring tone that
tional POTS like application. the calling subscriber hears is stopped by sending the mes-
The code describes the situation which occurs when a sage stopitone to the process A ( A ! stopitone), and a mes-
call is being set up. We assume that the calling (or A) sub- sage is sent to the called partner to abandon the call attempt
scriber has dialled a valid number and the called (or B) (B ! terminate). Finally, the function idle(A) is evaluated.
number was free. If the called partner answers, the ringing tone is
In such circumstances the caller will hear a ring tone, removed and the switch started (startiswitch(A,B)).
and the called subscribers phone will be ringing. The call is now in progress and the functions
This situation can be described by a pair of communi- conversationia and conversationib will control future pro-
cating functions ringingia/2 and ringingib/2. gress in the call.
ringingia(A, B) -> One further point to note about the receive primitive
receive 10 { is that it is selective, that is to say it takes the first message
A ? onihook => that matches from a queue of messages that are waiting for
A ! stopitone, the attention of the receiving process. It also queues any
B ! terminate, unmatched messages.
idle(A); In our previous example the process which was
B ? answered => evaluating the function ringingia was expecting one of the
A ! stopitone, messages onihook or, answered. Any other messages which
startiswitch(A, B), arrive at the process while it is waiting will be automatically
conversationia(A, B); queued for future processing.
timeout =>
A ! stopitone, For example: Suppose the following messages have
B ! terminate, been sent (but not yet received) to a process, eventually they
waiticlear(A) end up in an input queue to the process:
}. p1,onihook
p2,offihook
p3,digit(3)
p3,digit(4)
...

The notation P,M means there is a message M from a

process P in the input message queue of the process
p1,onihook is the first entry in the queue.
A receive statement of the form:
 receive { p1 ? onihook => ... } 4.2. Simple Example
would remove the top item in the queue, whereas, In the following example evaluating the function init
creates two processes, the child process (which is evaluating
receive { Id ? digit(Digit) => ... } the function driver:start) is linked to the parent process
(which is evaluating the function monitor).
would remove the third entry of the queue binding the
variables Id to p3 and Digit to 3. After the reception of this init ->
message the state of the input queue would be: processiflag(trapiexit, yes),
spawnilink(driver:start, 10),
p1,onihook
monitor.
p2,offihook
p3,digit(4) Spawnilink is an atomic command equivalent to
... spawn immediately followed by a link command. This is to
prevent the situation where a process can die before it is
The selective behaviour of receive is intended so that
linked so that the parent process never sees the exit signal.
Erlang programs can easily model CCITT SDL [5]
processiflag(trapiexit, yes) is a command which when
specifications. In SDL message reception unwanted mes-
evaluated tells the system to allow this process to treat exit
sages can be saved for later processing. The mechanism is
signals as if they were normal inter-process messages (i.e.
implicit in Erlang.
they can be received within receive statements).
The advantage of embedding a fairly sophisticated
monitor ->
message reception mechanism in the language frees the pro-
receive {
grammer from worrying about what to do with messages
Id ? Mess =>
that should be processed at a later time (a common problem
write(received(Id, Mess));
in telephony programming). This mechanism also avoids
exit(Id,Why) =>
some of the deadlock problems which occur in languages
write(processiexited(Why)),
like Occam, CSP or Parlog where an unexpected message
spawnilink(driver:start)
can permanently block a communication channel.
},
4. ERROR DETECTION AND monitor.
RECOVERY
If a run time error occurs in the child process, an exit
Erlang provides a sophisticated error detection signal will be sent to the parent process. This will be
mechanism. The purpose of the error detection mechanism is trapped by the parent process since it has previously issued a
to allow the system to take certain default actions in the processiflag(trapiexit, yes) command.
event of an unplanned event.
The parent traps the exit signal as follows:
Using the error detection mechanisms programs can
be written to build a system which can restore itself to a receive {
safe state in the event of certain classes of error. exit(Id,Why) =>
...
The error detection mechanism provides a method }
whereby one process can monitor the behaviour of another
process. If the monitored process dies then the monitoring Id will be bound to the process name of the daughter
process is informed - it can then take actions to protect the process and Why will be bound to a term describing the rea-
system and restore it to a safe state. son for the exit signal.

4.1. Basic Mechanisms 4.3. A Robust Server

The error recovery mechanisms used in Erlang can be The following example will demonstrate how we can
described in terms of two concepts, process links and exit construct a robust device allocation process. Let us suppose
signals. During execution, processes can establish links that we have a number of resources (represented by
between themselves and other processes. The set of processes) which are allocated by a common device alloca-
processes to which a given process is linked we call the link tion process. The top loop of the device allocation process
set of the process. can be written as follows:
If a process terminates abnormally (with a run-time top(Free, Allocated) ->
error) then on termination a special exit signal is sent to all receive {
the processes in its link set. If a process terminates normally Id ? alloc =>
then an exit(normal) signal is sent to all the processes in its topialloc(Free, Allocated, Id);
link set Id ? release(Resource) =>
On receipt of an exit signal the default action of the Allocated1 = delete({Resource,Id}, Allocated),
receiving process is to terminate and send exit signal to all top([ResourceeFree], Allocated1)
the processes in its link set. An exception to this is when the }.
signal exit(From,normal) is received - such a signal is sim- topialloc([], Allocated, Id) ->
ply ignored. Id ! no,
The default handling of exit signals can be over- top(Free, Allocated).
ridden to allow a process to take any required action on topialloc([ResourceeFree], Allocated, Id) ->
receipt of an exit signal. Id ! yes(Resource),
top(Free,[{Resource,Id}eAllocated]).
 delete(H, [HeT]) -> must have previously evaluated the processiflag(trapiexit,
ˆT. yes) function) - the server establishes which resource was
delete(X, [HeT]) -> allocated to the terminating process (by examining the allo-
T1 = delete(X, T), cation list with the function lookup) and releases the
ˆ[HeT1]. resource for future use. In addition, any links between the
client and server are automatically removed.
A process that wishes to reserve one of the devices
being managed by the device allocation process sends a 4.4. Error Kernels
message alloc to the process and waits for the reply no
(indicating that no resource is available) or yes(Process) In the previous section we showed how to construct a
indicating that Process has been allocated to the requesting robust device allocation server. This server should function
process. correctly in the presence of programming errors in the client
processes. This leads us to the observation that not all code
When the requesting process has finished with the in a large system has to be correct in order that the system
resource it sends the message release(Resource) to the as a whole should provide acceptable behaviour. By accept-
resource allocation process. able we mean that at some level the system can protect itself
The resource allocation process maintains two lists, from minor errors.
Free a list of the free processes, and Allocated a list of An extension of this observation leads to the concept
{Resource,Id} pairs which remembers which Resource of an Error Kernel.
Resource has been allocated to which process Id.
The Error Kernel we define to be the smallest part of
Such a server will work correctly if we can guarantee a system which has to be correct in order that the system as
that the client processes obey the client/server protocol. In a whole should provide acceptable behaviour.
other words, we must guarantee that the client process
releases the reserved resources when they are finished with One of the major goals of system design should be to
them. isolate the Error Kernel and to program it in as clear a
manner as possible so as to increase the probability that it is
Let us now suppose that a programming error occurs correct. Formal tools and proof proceedures then only need
in the client process. In such circumstances the client may to be applied to the code in the error kernel and not to the
terminate abnormally and therefore not send a release mes- entire system.
sage to the allocation process. This situation can be handled
with the following modification to the allocation process: Empirical studies (not described here) have shown
that the error kernel for a system comprising some tens of
topirecover(Free, Allocated) -> thousands of lines of Erlang code can be as small as a few
receive { hundred lines.
Id ? alloc =>
topirecoverialloci1(Free, Allocated, Id); 5. IMPLEMENTATION
Id ? release(Resource) => Several Erlang interpreters have been written in vari-
unlink(Id), ous prologs and ported to a number of different machines
Allocated1 = delete(Resource, Allocated), (VAX 11/750, SUN 3/60, PC/AT). These interpretors have
topirecover([ResourceeFree], Allocated1); been used to control experimental hardware (see [3] for
exit(Id, Reason) => further details) from the Ericsson MD 110 PABX [6] system
Resource = lookup(Id, Allocated), which is connected to a network of SUN 3/60 workstations.
Allocated1 = delete(Id, Allocated), Distribution is provided by using the MD-110 Group switch.
topirecover([ResourceeFree], Allocated1);
The performance of the current interpretor has proved
}.
adequate for experiments in telephony programming. The
purpose of these experiments was to evaluate Erlang as a
topirecoverialloci1([], Allocated, Id) ->
programming language for programming telephony applica-
Id ! no,
tions. In this evaluation we were interested in clarity of
topirecover(Free, Allocated).
expression rather than performance.
topirecoverialloci1([ResourceeFree], Allocated, Id) ->
Id ! yes(Resource), Future implementations will concentrate on improved
link(Id), performance - we are, for example, investigating how Erlang
topirecover(Free, [{Resource,Id}eAllocated]). can be compiled to a flat concurrent logic programming
language such as STRAND [7] or KL/1.
lookup(Id, [{Resource,Id}ei]) ->
ˆResource. 6. CONCLUSIONS
lookup(Id, [ieAllocated]) -> We have presented a language designed for building
lookup(Id, Allocated). prototypes of concurrent real time robust distributed applica-
In this example we have modified the previous code tions. The language is free from side effects and contains
so that when a resource is allocated to a client process a link mechanisms with which robust systems can be programmed.
is created (by evaluating the link(Id) function) between the An explicit notion of concurrency and an in-built error han-
client and the resource manager. dling mechanism alows many of the problems encountered
in interaction between a language and conventional operating
If the client releases the resource in the normal system to be avoided.
manner (with a release message) the link is removed (by
evaluating the unlink(Id) function) .
If the client terminates without releasing the resource
then an exit signal is received by the server (note that it
7. ACKNOWLEDGEMENTS We wish to ack-
..
nowledge the valuable contributions of Bjarne Dacker,
.. °
Goran Bage, Anders Gustafsson, Per Hedeland and Mike
Williams to the language.
We also wish to thank the the users of Erlang, whose
patience, enthusiasm and tenacity has never diminished
despite many non-backwards compatible changes to the
language.

REFERENCES
..
[1] Dacker B., Elshiewy N., Hedeland P., Welin C-W. and
Williams M. C., Experiments with Programming Languages
and Techniques for Telecommunication Applications Proc.
6th Int Conf. on Software Engineering for Telecommunica-
tion Switching Systems, Eindhoven, The Netherlands, 14-18
April 1986.
[2] Armstrong, J. L., Elshiewy, N. A. and Virding, S. R.,
The Phoning Philosopher’s Problem or Logic Programming
for Telecommunications Applications Third IEEE Sympo-
sium on Logic Programming, September 23-26, 1986, Salt
Lake City, Utah
[3] Armstrong, J.L., Williams, M.C. Using Prolog for Rapid
Prototyping of Telecommunications Systems. 7th Int Conf.
on Software Engineering for Telecommunication Switching
Systems, Bournemouth 3 - 7 July 1989.
[4] Clocksin W. F. and Mellish, C. S. Programming in Pro-
log. Springer Verlag 1981.
[5] CCITT Recommendation Z.100 Specification Description
Language. (SDL)
[6] Reprint of Ericsson Review articles on MD 110 from nos
1 and 2 1982
[7] STRAND: New Concepts in Parallel Processing. Ian
Foster and Steven Taylor. Prentice Hall, 1989.