This document provides an introduction to functional programming with Erlang. It discusses Erlang's history and origins at Ericsson to build robust, fault-tolerant systems. Key properties of Erlang are highlighted like concurrency, hot code loading, distribution, and soft real-time capabilities. Basic concepts in Erlang like functions, data types, pattern matching, modules, and recursion are explained. Examples of Erlang use in companies and products are also given.

1. Introduction to Functional Programming
Vasilij Savin
AACIMP 2011

3. Background: Telecom issues
● No down time allowed
● Solution has to be VERY scalable (millions
operations per second)
● Maintainable software
● Distributed systems

4. History of Erlang
● Need for robust fault-tolerant language
● Ericsson did not find one to suit the needs
● Based originally on Prolog
– Inherits many syntax concepts
● Later rewritten with C for performance
● Opensource from 2001

5. Erlang distinguished properties
● Concurrency
● Hot code loading
● Distributed
● Soft real-time
● Robust

6. What Erlang is NOT?
● Object-oriented
● C syntax follower
● Shared memory ideology follower
● SILVER BULLET

7. What Erlang is NOT good for?
● Front-end web development
● GUI programming
● Desktop applications

8. Erlang in the Real World: Companies
● Klarna (e-commerce)
● Mobile Arts (telecom)
● Ericsson (telecom)
● Goldman Sachs (banking)
● Facebook (social network)

9. Erlang in the Real World: Products
● Ejabberd (instant messanging server)
● YAWS (webserver)
● Facebook chat
● Firmware in Ericsson products
● Varios telecom services

10. Paradigm comparison
Imperative (structured, Functional
procedural)
Treats computation as the
Computation in terms of evaluation of mathematical
statements that directly functions avoiding state
change a program state and mutable data.
Object-oriented
Treats datafields as
"objects" manipulated only
through pre-defined
methods

11. The biggest challenge ahead:
Unlearning what you already know

12. Basic Concepts
● Functions are First Class citizens
● Functions are purely functional
● Iteration is achieved through recursion
● Execution Flow control is done with pattern
matching

13. Data Types
● Integers
● Floats
● Atoms
● Lists
● Tuples

14. Integers
● B#Val is used to store > 16#FF.
numbers in base < B >
255
● $Char - ascii value > $B.
● Large integers are converted 66
to bignums
● Max size depends on physical
constraints

15. Floats
● Calculations are not very -123.456
efficient
12.24E-10
● Stored as double
● Follow IEEE 754 standard

16. Atoms
● Atoms are constant literals magic_tag
● Start with a lower case letter 'A quoted tag'
or are encapsulated by ’ ’ '_can include blanks'
● Any character code is allowed
within an atom if using ’ ’
● Letters integers and _ are
allowed if the atom starts with
a lower case letter

17. Tuples
● Tuples are used to store a {123, bcd}
fixed number of items
{123, def, abc}
● Tuples of any size are allowed {person, 'Bass', 'Savin'}
● Must contain valid Erlang {abc, {def, 12.3}, “jkl”}
expressions
{}
● Tuple Arity – number of
elements in tuple

18. Lists
● Used to store a variable [1,2,'quoted
number of items Atom',atom,"str",123.12,
{tuple,1}]
● Lists are dynamically sized
> [97,98,99,4,5,6].
● Strings in Erlang are lists of
ASCII values [97,98,99,4,5,6]
● Lists are written beginning > [233].
with a [ and ending with a ] "é"
● Elements are separated by > [65,66,68].
commas
"ABD"

19. Lists II
● A recursive list definition “ABC” “DEF” == “ABCDEF”
consists of a head and a tail
Not recommended
● Lists whose last Tail term is [] (inefficient)
are called: proper lists > [1,2,3,4] – [2,3].
● Appended automatically [1,4]
● Improper lists are of limited > [1,2,3] ++ [4,5,6].
use [1,2,3,4,5,6]

20. Variables
● Variables start with an Upper A_Variable_name
Case Letter or _.
AnotherWayForVariable
● They may not contain any _do_not_care_variable
special characters.
_
● '_' alone is a don’t care
Variable. Its values are
ignored and never bound.
● The value of a variable can
not be changed once it
hasbeen bound.
● Erlang does not have a type
system.
● Types are determined at run
time.

21. Modules
● Modules are stored in files with the .erl extension
● The module and file names must be the same
● Exported functions can be called from outside the module
● Use the module prefix when making the call
– <module>:<function_name>([arg list]).
● Local functions can only be called within the module

22. Module anatomy

23. Functions
● Erlang programs consist of functions
● Functions are defined within Modules
● Function and module names must be atoms
● A function is defined as a collection of clauses
● Variables are pattern matched in the function head. If pattern
matching fails on a clause, the next one is tested. One clause
must always succeed
● Functions return value of the last expression executed

24. Function anatomy

25. Pattern Matching:
<Pattern> = <Expression>
Pattern Matching is used for:
● Assigning values to Variables
● Controlling the execution flow of the programs
● Extracting values from compound data types

26. Pattern Matching: Assignment
● The Pattern can
containunbound variables
which are bound when the A = 10.
pattern matching succeeds Str = “nice string”.
● The Expression may not List = [1,2,3].
contain unbound variables
Tuple = {abc, List, Str}
BadTuple = {List, Data}
fails

27. Pattern Matching: Testing
● A match must either succeed {A, A, B} = {10, 20,
or fail “str”}
● Used to pick the execution fails
flow in: [A, B] = [1, 2, 3, 4]
– case statements fails
– receive statements [A, B | C] = [1,2,3,4,5]
– function heads succeeds
A = 1, B = 2, C = [3,4,5]

28. Pattern Matching: Value Extraction
● Used to extract values from complex data types
● Note the use of _, the don't care variable
{_, Name, {Street, City, _}} =
{person, “Vasilij”, {“Kantatvagen”, 'Stockholm',
sweden}}

30. Case Anatomy

31. Case statement
● One branch must always succeed
● By putting the ‘_’ or an unbound variable in the
last clause ensures that the clause will always be
picked should the previous ones not match
● The _ clause is not mandatory

32. Guards
● Guards are additional clauses that can go in a function's head to
make pattern matching more expressive.
● All variables in guards have to be bound
● If all guards have to succeed, use , to separate them
● If one guard has to succeed, use ; to separate them
● Guards have to be free of side effects
● There are restrictions on BIFS and expressions in guards
● User functions are not allowed in guards
foo(String) when is_list(String), length(String) < 10 →
...
foo(Tuple) when is_tuple(Tuple);is_atom(Tuple) → ...

33. Recursion examples
odd([Head|Tail]) when Head rem 1 == 0 ->
[Head|even(Tail)];
odd([_Head|Tail]) ->
even(Tail);
odd([]) ->
[].

34. Recursion with accumulators
average(X) -> average(X, 0, 0).
average([H|T], Length, Sum) ->
average(T, Length + 1, Sum + H);
average([], Length, Sum) ->
Sum / Length.

35. Runtime Errors
● badarg – BIF with wrong arguments is called
● badmatch – patternmatching failed and clause list
is exhausted
● function clause – no function clause matched the
pattern

36. Useful libraries
● io.erl – general I/O functionality
● file.erl – general filesystem functionality
● lists.erl – helpful list function
More documentation can be found here:
http://www.erlang.org/doc/