An introduction to Core Erlang

Richard Carlsson
Computing Science Department
Uppsala University
Box 311, 751 05 Uppsala, Sweden
richardc@csd.uu.se

ABSTRACT termination; thus, unless the program sends a message to an-

Core Erlang is a new, o ial ore language for the on ur- other pro ess (or otherwise auses a side ee t), its exe ution
rent fun tional language Erlang. Core Erlang is fun - will not be visible to the rest of the system. Many Erlang
tional, stri t, dynami ally typed, pattern mat hing, higher programs are therefore written to run in a re ursive loop,
order and on urrent. It has been developed in ooperation a ting on in oming messages by performing some omputa-
between the High-Performan e Erlang proje t at Uppsala tion and sending o new messages, in a server-like manner.
University and the Erlang/Open Tele om Platform devel- Sin e the number of iterations is unbounded, Erlang im-
opment team at Eri sson, and is a entral omponent in the plementations must perform tail all optimisation, allowing
new release of the Erlang/OTP ompiler. This paper de- a pro ess to run forever in onstant spa e.
s ribes the ore language, its relation to Erlang, and the
history of its development. We show examples of translation The Erlang language is higher-order, stri t, and dynam-
from Erlang to Core Erlang, illustrating how analysis i ally typed. The primary basi types are atoms (names),
and transformation of Erlang programs is greatly simpli- arbitrarily-sized integers, oating-point numbers, the empty
ed by being performed at the ore language level. list (written [ ℄), and pro ess identiers. The only data on-
stru tors are n-tuples, written {t1 , : : :, tn } and ons ells
[ t 1 | t 2 ℄. Strings are represented by lists of integers ( har-
1. INTRODUCTION a ter odes). A very ommon idiom in Erlang is to pla e
1.1 The Erlang language an atom in the rst element of a tuple, as a tag indi ating
Erlang [1, 3℄ is a on urrent fun tional language devel- its ontents: for example, the nodes of a syntax tree ould
oped by Eri sson, whi h is today being used in several large be represented by { onstant, : : :}, {lambda, : : :}, {apply,
real-world appli ations, with a ode base of millions of lines ::: }, et .; a pro ess ould in a ertain state be interested only
of ode. The main design goals for Erlang have been in- in messages on the form {reply, Sender, Value}, and so
reased produ tivity, error avoidan e, on urren y and ro- on.
bustness; for these reasons, it is largely side ee t free, the
main sour e of side ee ts being the sending of messages. Erlang has for histori al reasons pi ked up a few synta -
ti al parti ularities from Prolog, the most prominent being
Erlang pro esses are very lightweight and are implemented that identiers are variables if they begin with an upper ase
at the abstra t ma hine level, rather than as operating sys- letter, and are otherwise atoms. Atoms that do not begin
tem threads, making it possible in pra ti e to run thousands with a lower ase letter, or ontain strange hara ters, must
of pro esses on a single ma hine. Communi ation between be written within single-quotes, like 'Atom' or '$trange'.
pro esses is handled by asyn hronous message passing, and
is transparent over network onne tions. Attempting to re- An Erlang program onsists of a set of modules, where ea h
eive a message from the pro ess mailbox will suspend the module denes a number of fun tions. A module is uniquely
pro ess until a mat hing message has arrived, or some ho- identied by its name as an atom. Within a module, ea h
sen timeout limit is ex eeded. fun tion is identied by its name (also an atom) and its
arity. It is thus possible  and often done  to have several
The ode exe uted by a pro ess is a fun tional program; fun tion denitions with the same name but with dierent
when the program terminates, so does the pro ess. The arities. For ea h module, only fun tions that are expli itly
value omputed by su h a program is always dis arded upon de lared as exported will be a essible from other modules.

The following is an example of a simple Erlang module:

-module(list).
-export([length/1, reverse/1℄).

length([X | Xs℄) -> 1 + length(Xs);

length([℄) -> 0.
 reverse(Xs) -> reverse(Xs, [℄). formations, advan ed inlining te hniques, and spe ialisation,
are not suitable or even possible to apply at that level. Stan-
reverse([X | Xs℄, Ys) -> dard lo al optimisations are of ourse done on the BEAM
reverse(Xs, [X | Ys℄); ode, but although important, these typi ally have too lim-
reverse([℄, Ys) -> Ys. ited s ope for any drasti improvements.

The third reason is that all attempts to simply redu e the

(Note that the fun tion whose name is reverse/2 is not language to a proper subset, ended up in onvoluted dis-
exported.) ussions about whether or not expression A really ould
be rewritten as expression B , sin e ex ept in a few ases,
Calls may be qualied with the name of the module, using neither was originally dened in terms of the other. Then,
the syntax Module:Fun tion(: : :). An external all to the even when semanti equivalen e ould be determined, it was
module above ould look like e. g. list:length(L). generally the ase that the rewritten, expanded expression
less
Erlang is dynami ode repla e-
would result in mu h e ient ode when passed through
An important feature of the ompiler, be ause that did in fa t need to identify ea h
ment : any module an be repla ed at run-time with a new sour e ode onstru t dire tly in order to generate reason-
version. Whenever a module-qualied fun tion all is made, ably good output.
the latest loaded version of the target module is used; this
applies even if the target is the same as the aller. Thus, if In 1998, dis ussions were started between the High-Perfor-
the re ursive loop of a server pro ess always does a qualied man e Erlang (HiPE) group at Uppsala University Comput-
tail all on ea h iteration, it will start exe uting the new ing S ien e Department and the OTP development team at
ode as soon as it loops ba k to handle the next request. Erlang. Sev-
Erlang implementations must allow for at least two ver-
Eri sson about a standard ore language for
eral dierent prototype representations were qui kly put to-
sions of a module to be stored in the system simultaneously: gether, but there was no agreement on the details of the
the urrent and the previous. If later the same module is re- language.
pla ed again, any pro ess that is still running old ode may
be automati ally found and killed, so that that ode an be In 1999, work began on reating a spe i ation, initially
safely purged from the system. by attempting to unify the existing suggestions, then by
renement and loser study of the many ne points of the
1.2 Core Erlang history semanti s ofErlang. Lots of hanges were ne essary before
Being a fun tional language semanti ally not far removed all involved were able to agree on a ommon ore language,
from S heme [10℄, Erlang should be well suited for the and it was not until late 2000 that version 1.0 of the Core
appli ation of many interesting analyses and performan e Erlang spe i ation [4℄ was nally available as a te hni al
improving transformations, from the well-known to the ex- report.
perimental. However, this has not yet been very su essfully
done. There are several reasons for this, all following from As of release 8 of the OTP/Open Sour e Erlang distri-
the fa t that the development of Erlang was always prag- bution, s heduled for O tober 2001, the ompiler now uses
mati ally oriented, rather than theoreti ally (or even very Core Erlang as an intermediate representation, is able to
systemati ally).
1 read and write Core Erlang ode in text form, and has
hooks for adding user-dened transformations at the Core
The rst reason is that as Erlang has evolved, its syntax Erlang level.
has be ome rather omplex. It is still on eptually a small
language, whi h makes it easy to learn, but the same fun - 1.3 Core Erlang design goals
tion an often be expressed synta ti ally in many dierent The following were our main design goals for the Core
ways. Thus, a program operating on sour e ode must han- Erlang language:
dle so many ases as to be ome impra ti al in general.

The se ond reason is that the original abstra t ma hine  It should be a stri t, higher-order fun tional language,
used for Erlang, the JAM [2℄ sta k ma hine, had an in- with a lear and simple semanti s.
stru tion set whi h was similar enough to the a tual sour e-
level language that no intermediate representation was ever  It should be as regular as possible, to fa ilitate the

used in the ompiler. When the new abstra t ma hine, the development of ode-walking tools.

BEAM [7℄ (a WAM-like register ma hine), was introdu ed,

 Translation fromErlang programs to equivalent Core
the sour e language was already xed, and even though in-
termediate representations be ame ne essary for the trans-
Erlang programs should be straightforward, and equally
important, it should be straightforward to translate
from Core Erlang to the intermediate ode used in
lation, these went as straight as possible to the abstra t ma-
hine level, in order to get orre t, working ode with the
least amount of trouble. However, both JAM and BEAM
Erlang implementations.
ode are imperative in nature, and most optimisations from
 There should be a well-dened textual representation
the fun tional programming world su h as algebrai trans-
of Core Erlang, with a simple, preferably unam-
1 The positive side of that oin is however that the language biguous grammar, making it easy to onstru t tools
is in fa t very useful for writing heavy-duty real-world pro- for printing and reading programs. This representa-
grams. tion should be possible to use for ommuni ation be-
 tween tools using dierent internal representations of relatively late,
2
and play a mu h more entral part in Core
Core Erlang. Erlang. The syntax is:
 The textual representation should be easy for humans
fun ::= fun (var 1 , ::: , var n ) -> exprs
to read and edit, in order to simplify debugging and var ::= VariableName
testing.
Where no variable may o ur twi e in var 1 ; : : : ; var n .
 The language should be easy to work with, supporting
To simplify generation of e ient ode, and to allow ertain
most kinds of familiar optimisations at the fun tional
optimisations to be performed at the ore language level,
programming level.
a Core Erlang expression always produ es a sequen e of
values, whi h ould be empty. Value-sequen es are writ-
Of these, the last was by far the most di ult to a hieve, ten within angular bra kets (less than/greater than); if the
trying to a omodate for the urrent or anti ipated needs of length is exa tly 1, the bra kets may be left out. Ea h om-
everyone involved. In the end, we hose not to enfor e any ponent expression expr 1 ; : : : ; expr n must produ e exa tly
spe i onvention su h as ontinuation-passing style or A- one value:
normal form; it is however an easy task to normalize any
exprs expr < expr 1 , , expr n >
Core Erlang program a ording to preferen e. ::= j :::

The use of an expression must mat h the number of values it

2. THE CORE ERLANG LANGUAGE produ es, whi h should be well-dened; if the expression is
2.1 Modules an argument to a onstru tor or fun tion all, this number
As in Erlang, all Core Erlang fun tions must reside should always be 1. However, it is not possible in general
within a module. A module de laration has the following to determine at ompile time that a given Core Erlang
form: program is orre t in this respe t.

module ::= module Atom [ fname i1 ,

: : :, fname i ℄
2.2 Expressions
k
attributes [ Atom 1 = onst 1 ,
Basi expressions in Core Erlang are variables (ordinary
variables and fun tion names), atomi literals, lambda ex-
: : :, Atom m = onst m ℄
pressions (funs), ons ell onstru tors, and n-tuple on-
fname 1 = fun 1
stru tors; all obviously produ ing exa tly one value. In ad-




dition there are let-expressions, whi h bind n variables si-
fname n = fun n end
multaneously to the values produ ed by the right-hand side,
where ea h fname is a fun tion variable with a spe ial syn- and the similar sequen ing expressions do, whi h bind no
tax: variables. Furthermore, letre expressions allow lo al (re-
ursive) fun tion denitions, whi h Erlang itself does not
fname ::= Atom / Integer have, but whi h are often useful in transformations.

Fun tion variables were not stri tly ne essary for the lan- expr ::= var j fname j lit j fun
guage, but make it easier to see the onne tion to the original
j [ exprs 1 | exprs 2 ℄
program, and keep the export me hanism simple, sin e the
external names are the same as the internal. The exported j { exprs 1 , : : :, exprs n }
fun tions are listed after the module name, and must be a j let vars = exprs 1 in exprs 2
subset of those dened in the top level of the module. j do exprs 1 exprs 2
Ea h module has a possibly empty set of attributes, where
j letre fname 1 = fun 1
the keys, whi h must be unique, are atoms and the or-


fname n = fun n in exprs

responding values are any onstant terms. The meaning apply exprs 0 (exprs 1 , : : :, exprs n )
Erlang
j
of module attributes is implementation-dependent;
j all exprs n+1 :exprs n+2 (exprs 1 , : : :, exprs n )
uses them for things su h as version information. Constant
terms are: j primop Atom (exprs 1 , : : :, exprs n )
j try exprs 1 at h (var 1 , var 2 ) -> exprs 2
onst ::= lit j [ onst 1 | onst 2 ℄
j ase exprs of lause 1


lause n end
j { onst 1 , : : :, onst n }
j re eive lause 1


lause n
lit ::= Integer j Float j Atom
after exprs 1 -> exprs 2
j Char j String j [℄
vars ::= var j < var 1 , : : :, var n >

Core Erlang, all atoms must be written within single Erlang has rather unusual s oping rules, making ode traver-
In
quotes, to avoid any onfusion with keywords.
Core Erlang, s opes are nested as in
sal di ult, but in
ordinary lambda al ulus.
2 Erlang was originally made a rst-order language, be-
2.1.1 Functions, lambdas and results of expressions ause it was thought that lambda abstra tions would make
Lambda abstra tions are for apparent reasons known as funs programs too ompli ated, and ould generally be done
in the Erlang parlan e. They were added to the language without.
2.2.1 Function calls lause ::= pats when exprs 1 -> exprs 2
Core Erlang fun tion alls ome in three avours: appli- pats ::= pat j < pat 1 , : : :, pat n >
ations, remote alls, and primitive operations. The rst is
simply the appli ation of a fun tional value (su h as a lo ally
pat ::= var j lit j [ pat 1 | pat 2 ℄
dened fun tion) to a list of arguments. j { pat 1 , : : :, pat n }
j var = pat
apply exprs 0 (exprs 1 , : : :, exprs n )
all exprs n+1 :exprs n+2 (exprs 1 , : : :, exprs n ) Patterns in lude the form var = pat , whi h is analogous to as
patterns in ML [9℄. Clauses are tried in order, until the rst
primop Atom (exprs 1 , : : :, exprs n )
with a mat hing pattern is found whose guard evaluates to
true. If no lause should mat h, the behaviour is undened.

A remote all (module-qualied all) has two subexpressions

A lause guard is a limited form of expression  it must
apart from the argument list: these must evaluate to atoms,
produ e a single boolean value (either of atoms true and
giving the module and fun tion name, respe tively, of the
false), and must not have side ee ts. Currently, only
remote fun tion to be alled. Usually, both are stati ally
variables, atomi literals, onstru tors, let-, do- and try-
known at ompile time, but they may be dynami ally om-
expressions, and primop and all alls to stati ally named
puted. For a remote all, the latest loaded version of the
fun tions are allowed in guards. Called operations and fun -
named module is always used; this allows migration from
tions must be guaranteed to exist and be free from side ef-
old ode to new, as previously des ribed.
fe ts: typi al examples are type tests, omparison operators
and sele tors.
Primitive operations are in luded to make a watertight dis-
ti tion between operations that are internal to the ompiler,
Error handling is also restri ted in guards. A try-expression
and normal fun tions that are exported by some module.
in a guard must have the following form:
The name of the alled operation must be a onstant. E. g.,
it ould be safe for the ompiler in ertain situations to intro- try exprs 1 at h (var 1 , var 2 ) -> 'false'
du e an operation at the Core Erlang level that destru - In other words, if the evaluation of the tried expression
tively updates a part of a data stru ture, but programmers
must be prevented from a essing su h operations dire tly
should fail, the ex eption is aught and the value false is

from Erlang, sin e unrestri ted use ould violate the lan- substituted for the result. This is used for supporting the
quite unorthodox way Erlang treats ex eptions in guard
guage semanti s.
expressions. It is possible that in future versions of Core
Erlang, fully general try expressions will be allowed in
guards.
2.2.2 Error handling
Core Erlang does not spe ify how ex eptions are gen-
2.2.4 Receive expressions
erated; only how they may be aught. An ex eption has
two omponents: the tag and the value. These may be any
Last, we des ribe the rather intri ate asyn hronous re eive
values, but the tag is expe ted to signify the lass of the ex-
expression. Its syntax is very similar to a ase expression:

eption; in Erlang, possible tags are urrently the atoms re eive lause 1


lause n
'EXIT' and 'THROW'. after exprs 1 -> exprs 2

try exprs 1 at h (var 1 , var 2 ) -> exprs 2 but it has no expli it sele tor, and adds a nal  lause for
timeouts.

A re eive expression impli itly ontains a loop, whi h is

In a try expression, if evaluation of the attempted expres-
the main reason why it annot be redu ed to simpler ompo-
sion should fail, raising an ex eption, then this will be aught
nents in a useful way. The exe uting pro ess will traverse its
and instead the alternative body of the try-expression will
mailbox queue, always from the beginning, and either sele t
be evaluated with var 1 bound to the tag and var 2 to the
the rst message that mat hes one of the lauses, removing
value of the ex eption.
the message from the mailbox and evaluating the lause, or
otherwise suspend until a mat hing message arrives or the
timeout limit is ex eeded. Time is given as an integer num-
2.2.3 Pattern matching ber of millise onds, zero meaning immediate timeout if no
LikeErlang, the ore language uses pattern mat hing for message mat hes. The atom infinity is used to signal that
de omposition and bran hing, but only in two onstru ts the timeout should never happen.
( ompared to six in Erlang), of whi h the rst is the ase
swit h. The sele tor expression produ es a xed number of It is obvious that attempting to break down this onstru t
values, and ea h lause, on the form patterns when guard -> will always expose the dierent possible states during traver-
body , must ontain the orresponding number of patterns. sal and mat hing, whi h ould jeopardise the integrity of the
Variables may not be repeated in the patterns of a lause, mailbox. What is perhaps even more important, de ompo-
and are always binding o urren es, whose s ope is the guard sition would make it mu h more di ult to use the ore lan-
and body expressions. guage for pro ess ommuni ation analysis. Therefore, the
re eive is arried over pra ti ally as it is from Erlang to
ase exprs of lause 1


lause n end Core Erlang.
2.3 Syntax summary <[X | Xs℄, Ys> when 'true' ->
Figure 1 shows a summary of the language syntax. let X3 = [X | Ys℄
in apply 'reverse'/2(Xs, X3)
3. TRANSLATION EXAMPLES <[℄, Ys> when 'true' -> Ys
As mentioned, the s oping rules of Erlang are rather un- <X3, X4> when 'true' ->
all 'erlang':'exit'('no_ lause')
usual; ea h expression has an input environment and an
output environment. It is e. g. possible to write:
end
end

f(X) ->
ase X of We see that all pattern mat hing is moved to ase expres-
{foo, A} -> B = g(A); sions, and that some of the run-time error he king done
{bar, A} -> B = h(A) by Erlang is made expli it by adding default lauses; in
end, the reverse/1 fun tion, this has been removed by elimi-
{A, B}. nating unrea hable ode. The evaluation order of Erlang
expressions is enfor ed by introdu ing let bindings during
translation. (In the above example this was not stri tly ne -
where the values of A and B in the resulting tuple depend essary.)
on the sele ted bran h. Maintaining input and output en-
vironments while traversing Erlang ode is umbersome Translating operators like + to qualied alls to the module
and error prone. Translating the above into Core Erlang erlang is done in order to have a normalised representation
might produ e the following ode: of standard operators, making it possible to write program
transformations that are not implementation dependent. In-

'f'/1 = fun (X) -> stead of presenting a list of o ial Core Erlang primops,
we use the fa t that these fun tions already have denitions
let <X1, X2> =
ase X of in the Erlang standard library. There should be no run-
time penalty indu ed by this, however, be ause the ompiler
{foo, A} when 'true' ->
is allowed to re ognize alls to su h built-in fun tions (BIFs)
let B = apply 'g'/1(A)
and generate more e ient ode for these, using the assump-
in <A, B>
tion that they will not be redened. In other words, a later
{bar, A} when 'true' ->
let B = apply 'h'/1(A) transformation stage ould rewrite su h alls to primop ap-
pli ations, making the program representation dependent of
in <A, B>
the parti ular ompiler implementation, as a prelude to low-
end,
level ode generation.
in {X1, X2}

whi h is mu h easier to traverse, manipulate and reason

4. RELATED WORK
Dam and Fredlund [5℄ and Hu h [8℄ have used ore fragments
about, following ordinary lambda al ulus s oping rules. This
example also illustrates one of the main reasons why Core or subsets of Erlang for purposes of program analysis (also
Erlang expressions produ e multiple values. and independently using the name Core Erlang).
subsets are however in omplete with respe t to representing
These

The Erlang module shown in Se tion 1.1 an be automati-

all possible Erlang programs, and are not entirely suitable
ally translated to the following Core Erlang ode, using
as an intermediate ode representation in the ompilation

the fa t that in Erlang, inx operators su h as + belong to

pro ess.

erlang:
the standard library module named
Feeley and Larose [6℄ (the ETOS proje t) ompile Erlang
by translation to S heme[10℄, but the generated S heme ode
module 'list' ['length'/1, 'reverse'/1℄ is too tightly oupled to their implementation to be useful as
attributes [℄ a generi intermediate format for Erlang. Furthermore, it
'length'/1 = does not seem feasible to perform e. g. program veri ation
fun (X1) -> or pro ess ommuni ation analysis using the output from
ase X1 of their translation.
[X | Xs℄ when 'true' ->
let X2 = apply 'length'/1(Xs) 5. CONCLUDING REMARKS
in all 'erlang':'+'(1, X2) We have des ribed the Core Erlang language, its rela-
[℄ when 'true' -> 0 tion toErlang, and the history of its development. Core
X2 when 'true' -> Erlang is today being used in the Erlang/OTP ompiler,3
whi h is the standard ompiler for the Erlang language.
all 'erlang':'exit'('no_ lause')
end Although the ompiler ba k end had to be modied to han-
'reverse'/1 = dle some of the onstru ts, this was not a major problem,
fun (X1) -> apply 'reverse'/2(X1, [℄) and in several ases leaned up the implementation. Fur-
'reverse'/2 =
fun (X1, X2) -> 3The Erlang/OTP ompiler, runtime system and libraries
ase <X1, X2> of are available as Open Sour e from http://www.erlang.org.
 module ::= module Atom [ fname i1 , : : :, fname ik ℄
attributes [ Atom 1 = onst 1 , : : :, Atom m = onst m ℄
fname 1 = fun 1


fname n = fun n end
fname ::= Atom / Integer
onst ::= lit j [ onst 1 | onst 2 ℄ j { onst 1 , : : :, onst n }
lit ::= Integer j Float j Atom
j Char j String j [ ℄
fun ::= fun (var 1 , : : :, var n ) -> exprs
var ::= VariableName
exprs ::= expr j < expr 1 , : : :, expr n >
expr ::= var j fname j lit j fun
j [ exprs 1 | exprs 2 ℄ j { exprs 1 , : : :, exprs n }
j let vars = exprs 1 in exprs 2
j do exprs 1 exprs 2
j letre fname 1 = fun 1


fname n = fun n in exprs
j apply exprs 0 (exprs 1 , : : :, exprs n )
j all exprs n+1 :exprs n+2 (exprs 1 , : : :, exprs n )
j primop Atom (exprs 1 , : : :, exprs n )
j try exprs 1 at h (var 1 , var 2 ) -> exprs 2
j ase exprs of lause 1


lause n end
j re eive lause 1


lause n after exprs 1 -> exprs 2
vars ::= var j < var 1 , : : :, var n >
lause ::= pats when exprs 1 -> exprs 2
pats ::= pat j < pat 1 , : : :, pat n >
pat ::= var j lit j [ pat 1 | pat 2 ℄ j { pat 1 , : : :, pat n }
j var = pat

Figure 1: Syntax summary

thermore, the ore language makes it possible to ontinue [5℄ M. Dam and L. Fredlund. On the veri ation of open
extending Erlang in a more systemati way than before. distributed systems. Te hni al Report R97-01,
Swedish Institute of Computer S ien e, 1997.
Our experien e (e. g., from the implementation of a re ent,
[6℄ M. Feeley and M. Larose. Compiling Erlang to
advan ed inlining algorithm, likely to be in orporated in the
standard ompiler) is that analysis and transformation of
S heme. In LNCS 1490, pages 261272.

Erlang programs is greatly simplied by being performed Springer-Verlag, 1998.

at the ore language level, whi h has only a few, simple and
[7℄ B. Hausman. Turbo Erlang: Approa hing the speed of
well-dened onstru ts, and uses ordinary s oping rules.
Implementations of Logi
C. In E. Ti k, editor,
Programming Systems. Kluwer A ademi Publishers,
6. ACKNOWLEDGMENTS 1994.
I would like to thank Kostis Sagonas for his advi e and om-
ments on versions of this paper. [8℄ F. Hu h. Veri ation of Erlang programs using
abstra t interpretation and model he king. In

7. REFERENCES Pro eedings of the ACM SIGPLAN International

[1℄ Armstrong, Virding, Wikström, and Williams.
Conferen e on Fun tional Programming, pages
261272. ACM Press, 1999.
Con urrent Programming in Erlang, Se ond Edition.
Prenti e Hall, 1996. [9℄ R. Milner, M. Tofte, R. Harper, and D. Ma Queen.

[2℄ J. Armstrong, B. Dä ker, R. Virding, and

The Denition of Standard ML (Revised). The MIT
Press, 1997.
M. Williams. Implementing a fun tional language for
Software
highly parallel real-time appli ations. In
[10℄ G. J. Sussman and G. L. Steele Jr. SCHEME, an
Engineering for Tele ommuni ation Swit hing interpreter for extended lambda al ulus. AI Memo
Systems, Floren e, Mar h 1992. 349, Mass. Inst. of Te hnology, Arti ial Intelligen e

[3℄ J. Barklund and R. Virding. Erlang 4.7.3 referen e Laboratory, Cambridge, Mass., De ember 1975.

manual. Draft version 0.7, June 1999.

[4℄ R. Carlsson, B. Gustavsson, E. Johansson,

T. Lindgren, S. Nyström, M. Pettersson, and
R. Virding. Core Erlang 1.0 language spe i ation.
Te hni al Report 2000-030, Department of
Information Te hnology, Uppsala University,
November 2000.