Recursion & Erlang, FunctionalConf 14, Bangalore

recursion and erlang
functionalconf ’14, Bangalore
Bhasker Kode 
Helpshift
@bhaskerkode @linesofkode
http://github.com/helpshift
git clone https://github.com/bosky101/fuconf

PART I
HISTORICAL walkthrough recursion
and erlang

automatic computing
Symposium. Germany, October 1955
ACM, US, 1957

goals of the IAL
mathematical notation
printable in publications
“should be able to be translated to
programs”

great strides
agreed upon the BNF
renamed from IAL to Algol
spanned 50 centres and 74 persons
formalized pass by value/reference
agreed to meet in 1960

features
variables
assignment
expressions
selection
iteration
maybe some sort of procedure

clashes
to use “,” or a “.” in numbers ?
US industrial programmers had real-world
inputs and recommendations
pass by reference was confusing
“Add recursion?” Lisp had just added
recursion few months before release

Dijkstra saw the potential of recursion.
With editor Naur, added it secretly to
the draft over phone from Amsterdam.
Hence called the “Amsterdam Plot”
Recursion was a major step. It was
introduced in a sneaky way.

1986
Erlang was designed for writing
concurrent programs that  
“run forever.”
Joe Armstrong at Ericsson Labs.
#telephony  
star #1 on erlang team

expressive
robust
object oriented
concurrency
ecosystem
long running
easy to debug
closures
immutability
single-threaded / multi-threaded
recursion
actor model
hot code loading
language design vs compiler design vs consequences

why concurrency was #1
Idea came from existing telephone exchanges
Lets say there are two separate phone calls
One call going down should not affect the other
They should not share anything, no sharing pointers
So copy data over. beginnings of message passing.
Be able to work on different registers
simultaneously.

thought process
with concurrency as the ﬁrst goal,
everything thing else was worked out
or a consequences around decisions
around concurrency

concurrency existed before
erlang
• Ada (with tasks)
• EriPascal (an Ericsson dialect of Pascal
with concurrent processes)
• Chill (with processes)
• PLEX (processes implemented in
hardware. Also inspired linking errors)
• and Euclid

#emp2 to #emp1
“3 properties of a programming language
were central to the efficient operation of a
concurrent language or operating system.“
1) the time to create a process.
2) the time to perform a context switch
between two different processes
3) the time to copy a message between two
processes

3 emps
“We rapidly adopted a philosophy of
message passing by copying and no
sharing of data resources. Again, this was
counter to the mood of the time, where
threads and shared resources protected
by semaphores were the dominant way
of programming concurrent systems.”

funny incident
• the 3 employees working on erlang
went to a conference just like this
• asked speakers what would happen if
one of the many machines crashes
• reply was “no failures” or “can’t do
anything” . This was still 1985.

• Joe armstrong first wrote this in the
algebra (hurray for algol 60 )
• a prolog engineer saw the algebra
and said, i can program this
• Joe was amazed. Learned prolog.

• prior to prolog, the implementation in smalltalk
• dial a number, send that as a message to
exchange.
• dial a valid number, other phone should ring
• if its busy, get back busy
• if its not busy, get back not busy

state machines
“the software for call control was best
modeled using finite state machines
that undergo state transitions in
response to protocol messages.”

What started as an experiment in
adding concurrency to Prolog,
became more of a language in its own
right and this language acquired a
name Erlang in 1987.

with concurrency as goal
“we didn’t realise at the time, was that
copying data between processes
increases process isolation, increases
concurrency and simplifies the
construction of distributed systems.”

history contd.
• http://www.erlang-factory.com/
conference/SFBay2010/speakers/
joearmstrong

PART II
under the hood of recursion

• usually a function gets executed and returns to
where it was called 
return 1 + foo(a)
• but in a tail optimised function, it effectively
does not have to remember where to go back
to 
return tail(1,a)
• #gajini

int r(int x) { 
if (x == 1) { 
return 1; 
} 
return x*r(x-1); 
}
r(3) 
!
!
recursive

int r(int x) { 
if (x == 1) { 
return 1; 
} 
return x*r(x-1); 
}
r(3) 
 
3 * r(2) 
3 * (2 * r(1)) 
3 * (2 * 1) 
3 * 2 
6
recursive

int tr(int x,int y){ 
if (x == 0) { 
return y; 
} 
return tr(x-1, x*y); 
} 
 
tr(3,1) 
!
!
tail recursive

if (x == 0) { 
return y; 
} 
} 
 
tr(3,1) 
 
tr(3-1, 3 * 1) 
tr(2-1, 2 * 3) 
tr(1-1, 1 * 6) 
6
tail recursive

int r(int x) { 
if (x == 1) { 
return 1; 
} 
return x*r(x-1); 
}
r(3) 
 
3 * r(2) 
3 * (2 * r(1)) 
3 * (2 * 1) 
3 * 2 
6
if (x == 0) { 
return y; 
} 
} 
 
tr(3,1) 
 
tr(3-1, 3 * 1) 
tr(2-1, 2 * 3) 
tr(1-1, 1 * 6) 
6
recursive tail recursive

• 3 procedural functions approach
• 1 recursive function approach
• 1 tail recursive function approach
see who is knocking on 3 doors

3 doors.  
“anybody here.no?ok.” x3

“anybody here.  
oh another door.”

“anybody here.  
oh another door”x 3  
oh a backdoor!”

3 * r(2) 
3 * (2 * r(1)) 
3 * (2 * 1) 
3 * 2 
6
tr(3-1, 3 * 1) 
tr(2-1, 2 * 3) 
tr(1-1, 1 * 6) 
6
are these both recursive?
which of these are easier to spawn off ?
which of these are easier to stop midway? 
which of these are easier to debug?

3 * r(2) 
3 * (2 * r(1)) 
3 * (2 * 1) 
3 * 2 
6
tr(3-1, 3 * 1) 
tr(2-1, 2 * 3) 
tr(1-1, 1 * 6) 
6
are these both recursive?
which of these are easier to spawn off ?
which of these are easier to stop midway? 
which of these are easier to debug?
recursive
good backtrace
cant change order
recursive
easier to parallelise

Amdahl’s Law
“The speedup of a program using  
multiple processors in parallel computing  
is limited by the time needed  
for the sequential fraction of the program.”

which brings us to  
spawning/forking
PART III
let’s look at some code

what is a daemon
• fair to say a daemon is a long running
process?
• fair to say a long running process is a tail-
recursive function?

rough skeleton for daemon in C

a long running process is
in fact a tail-recursive
function
a daemon in erlang

Does this block the scheduler? is this an infinite loop?
!
Let’s start foo and bar on new processes and see what
happens?!

runs a function as a new process. here
we ask it to spawn both foo, then bar.
spawn

erlang’s scheduler splits CPU time
between multiple concurrent processes
based on the “reductions” ( # times a
function is called)
use 8 cores,
so 8 schedulers

fork and start a daemon
that again does nothing…

as long as the heart is beating, you are alive
same way: as long as a process is  
a) tail-recursive or 
b) waiting to receive ( on its inbox ) 
…it is alive

#expressive #erlang
!
compose to suit
your needs

#expressive  
#erlang
!
tail-recursion 
+ 
network 
programming 
= killer combo

still think erlang has 
hard to read syntax?
busting some erlang mythsbusting some erlang myths

Leslie Lamport , “father of distributed
computing” recent Turing Awardee
said that if you are not representing
your distributed program as a state
machine you’re doing something
wrong.
PART III conclusion

tail resursive functions are the foundation for
processes
processes are the foundation for state
machines
tail recursive functions / processes with sockets
are the foundation for network programming
networking programming is the foundation of
distributed computing.
PART III conclusion

erlang & distributed systems
so in other words, erlang’s strength in
distributed computing can be
indirectly be attributed to supporting
tail recursion

Concurrency comes with its 
challenges

parallelism and ordering, another great debate
and tale of priorities and compromises
found in any producer/consumer scenario
1,2,3,4,5,6
1,2
3
4
5
6
5,4,1,2,3,6
eg: ekaf_partition_strategy
}

why state machines
send(Socket, Data) 
Foo = receive(Socket)

socket already closed, re-open it
socket already open
data being received currently
data being sent currently
socket closed before sending
socket closed before receiving
timeouts
and lastly, not friendly towards batched sending

“India can never join the G7. Why?”
@linesofkode

“Because if they do, it’ll be the G8”
recursion and erlang #ftw
Bhasker Kode 
Helpshift
@bhaskerkode

BONUS PART V  
( if we have time)
are language designers sadists?

weird syntax/semantics 
immutable variables
monkey patching
boilerplate code
callback hell 
weird stack traces 
bad handling of floats
whitespace, colons, semicolons, comma,
arrows

compiler design vs language goals  
vs consequences

expressive
robust
object oriented
concurrency
ecosystem
long running
easy to debug
closures
immutability
single-threaded / multi-threaded
recursion
actor model

expressive!
robust!
object oriented!
concurrency!
ecosystem!
long running!
easy to debug!
closures!
immutability!
single-threaded / multi-threaded!
actor model!
recursion!

So, No.  
Language designers do not draw joy
making you cringe.

language designer: “i want to be concurrent”
compiler designer: “ok, lets try not bottle necking on resources. that way
it’ll be easier to garbage collect.”
language: ”ok, i’ll favour immutability. this may mean recreating entire
Objects/trees/structures and passing them around.  
OO folks wont like this”
compiler: “btw since variables won’t change, can i re-use the call frame.”
language:”ok. as I need to add the sum of 100 numbers, i’ll create A1=1,
A2=increment(A1), …A100 = increment(A99)”
compiler: that looks too repetitive. use A = increment(100, previous) and
write a recursive fn that calls itself until 0.

concurrency
OO
mutability
recursion
message  
passing
speed
if you were to pick
1 as your top priority
and see its effects

concurrency
OO
mutability
recursion
message  
passing
speed
1

CPS
readability
debugging
tail call  
optimised
threads
1

• Guido, was in favour of not loosing stack
traces, and the fact that tail-call optimised
functions would be tougher to debug
• Trivia Alert! An early contributor to
python was an anonymous lisp hacker
“Amit Prem" who added
map,reduce,lambda to python in 1.0.0
TCO/recursion in other languages

• java compiler doesnt tco
• but scala allows tail recursive functions
• infact if you mention @tailrec it wont
compile until you make the function tail
recursive
• lua compiler does tail call optimisation

• The ECMAScript 4 spec was originally going to add
support for TCO, but it was dropped.
• But ECMAScript 6 does, but it only becomes a
standard mid 2015 ( PS: it also has destructuring
which is cool)
• in C compilers , do tail call optimisation but not
necessarily support tail recursion ( where the last
function is intact the same function )

pseudo-code notes
# not tail call optimised but is recursive 
a(n){ 
…. 
return 1 + a(n-1) 
}
# is tail call optimised but not recursive 
a(n){ 
…. 
return b(n-1) 
} 
 
# is tail call optimised and is recursive 
a(n){ 
…. 
return a(n-1) 
}

• in erlang, if a function a calls b, and a function b
calls a, its memory foot print will never increase.
• infact all process that receive messages need to
be tail-recursive
• this is the fundamental construct behind long
lived processes and building state machines in
erlang
TCO/recursion in erlang

recursion and erlang #ftw
Bhasker Kode 
Helpshift
@bhaskerkode

Recursion & Erlang, FunctionalConf 14, Bangalore

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Recursion & Erlang, FunctionalConf 14, Bangalore

Similaire à Recursion & Erlang, FunctionalConf 14, Bangalore (20)

Plus de Bhasker Kode

Plus de Bhasker Kode (7)

Dernier

Dernier (20)

Recursion & Erlang, FunctionalConf 14, Bangalore