This document discusses a function-passing programming model for distributed systems. The key concepts are: 1. Immutable, stationary data stored in "silos". 2. Portable "spore" functions that are serialized and sent to remote silos to perform work on the data. Silos contain the data and run functions on it. Silo references allow applying functions asynchronously across machines by serializing the functions and data references. The model aims to simplify distributed programming by keeping data stationary and moving functions to the data.

1. Function-Passing Style
Typed, Distributed Functional
Programming
Heather Miller
@heathercmiller
Philipp Haller
@philippkhaller
EPFL Typesafe

2. …been working on
Language support for distributed
system builders.
Serialization
That happens mostly at compile
time, so it’s performant.
Type classes to allow users to
serialize to different formats
(binary, JSON, etc)
1.

3. …been working on
Language support for distributed
system builders.
Spores
Portable (serializable) closures.
Type constraints to restrict what
they capture
2.

4. In this talk…
A programming model.
Builds on the basis of serializable
functions
to provide a substrate that
distributed systems can be built
upon

5. In this talk…
A programming model.
The result…
the model greatly simplifies the design
and implementation of mechanisms for:
Fault-tolerance
In-memory caching
Debugging(i.e., pushing types into
more layers of the stack)
IN A CLEAN & FUNCTIONAL WAY.
(STATELESS!)

6. Note:
Currently a research project.
Thus, all aspects of it are under
development + publication in
the works.
(Thanks, )

7. FUNDAMENTAL
IDEA:

8. FUNDAMENTAL
IDEA:
Inversion of the actor model.
Can be thought of as a dual to actors.

9. FUNDAMENTAL
IDEA:
Inversion of the actor model.
Can be thought of as a dual to actors.
A DUAL WHICH NICELY
COMPLEMENTS ACTORS!

10. Um,
HOW?

11. Actors…
Encapsulate state and behavior.
Are stationary.
Actors exchange data/commands
through asynchronous messaging.

12. Function-passing…
Stateless. Built on persistent
data structures.
Keep the data stationary.
Functions are exchanged through
asynchronous messaging.

13. Function-passing…
Stateless. Built on persistent
data structures.
Keep the data stationary.
Functions are exchanged through
asynchronous messaging.
Of note:
This is a model for programming with data and not a new
model of concurrent processes like actors.
!
Instead, we provide a new means of working with
distributed data in a functional way.

14. A Note on Distributed Computing
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall
Sun Microsystems Laboratories
2550 Garcia Avenue
Mountain View, CA 94043
1 Introduction
Much of the current work in distributed, object-oriented
systems is based on the assumption that objects form a sin-gle
ontological class. This class consists of all entities that
can be fully described by the specification of the set of
interfaces supported by the object and the semantics of the
operations in those interfaces. The class includes objects
that share a single address space, objects that are in sepa-rate
address spaces on the same machine, and objects that
are in separate address spaces on different machines (with,
perhaps, different architectures). On the view that all
1.1 Terminology
In what follows, we will talk about local and distributed
computing. By local computing (local object invocation,
etc.), we mean programs that are confined to a single
address space. In contrast, we will use the term distributed
computing (remote object invocation, etc.) to refer to pro-grams
that make calls to other address spaces, possibly on
another machine. In the case of distributed computing,
nothing is known about the recipient of the call (other than
that it supports a particular interface). For example, the
client of such a distributed object does not know the hard-ware
architecture on which the recipient of the call is run-ning,

15. A Note on Distributed Computing
Differences in latency, memory access, partial failure, and
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall
concurrency make merging of the computational models of local
and distributed computing Sun Microsystems both unwise Laboratories
to attempt and unable to
succeed.
2550 Garcia Avenue
Mountain View, CA 94043
1 Introduction
Much of the current work in distributed, object-oriented
systems is based on the assumption that objects form a sin-gle
ontological class. This class consists of all entities that
can be fully described by the specification of the set of
interfaces supported by the object and the semantics of the
operations in those interfaces. The class includes objects
that share a single address space, objects that are in sepa-rate
address spaces on the same machine, and objects that
are in separate address spaces on different machines (with,
perhaps, different architectures). On the view that all
1.1 Terminology
In what follows, we will talk about local and distributed
computing. By local computing (local object invocation,
etc.), we mean programs that are confined to a single
address space. In contrast, we will use the term distributed
computing (remote object invocation, etc.) to refer to pro-grams
that make calls to other address spaces, possibly on
another machine. In the case of distributed computing,
nothing is known about the recipient of the call (other than
that it supports a particular interface). For example, the
client of such a distributed object does not know the hard-ware
architecture on which the recipient of the call is run-ning,
“
”

16. A Note on Distributed Computing
Differences in latency, memory access, partial failure, and
Jim Waldo, Geoff Wyant, Ann Wollrath, and Sam Kendall
concurrency make merging of the computational models of local
and distributed computing Sun Microsystems both unwise Laboratories
to attempt and unable to
succeed.
2550 Garcia Avenue
Mountain View, CA 94043
A better approach is to accept that there are irreconcilable
differences between local and distributed computing, and to be
conscious of those differences at all stages of the design and
implementation of distributed applications. Rather than trying to
merge local and remote objects, engineers need to be constantly
reminded of the differences between the two, and know when it
is appropriate to use each kind of object.
1 Introduction
Much of the current work in distributed, object-oriented
systems is based on the assumption that objects form a sin-gle
ontological class. This class consists of all entities that
can be fully described by the specification of the set of
interfaces supported by the object and the semantics of the
operations in those interfaces. The class includes objects
that share a single address space, objects that are in sepa-rate
address spaces on the same machine, and objects that
are in separate address spaces on different machines (with,
perhaps, different architectures). On the view that all
1.1 Terminology
In what follows, we will talk about local and distributed
computing. By local computing (local object invocation,
etc.), we mean programs that are confined to a single
address space. In contrast, we will use the term distributed
computing (remote object invocation, etc.) to refer to pro-grams
that make calls to other address spaces, possibly on
another machine. In the case of distributed computing,
nothing is known about the recipient of the call (other than
that it supports a particular interface). For example, the
client of such a distributed object does not know the hard-ware
architecture on which the recipient of the call is run-ning,
“
”
“
”

17. So,
WHAT DOES
IT LOOKLIKE?

18. Function-Passing
Model
the
(illustrated)

19. Function-Passing
Model
the
Two concepts:
(illustrated)

20. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.

21. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.
Portable functions –
move the functionality to the data. 2.

22. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.
Silos
Portable functions –
move the functionality to the data. 2.

23. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.
Silos
(for a lack of a
better name)
Portable functions –
move the functionality to the data. 2.

24. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.
Silos
(for a lack of a
better name)
Portable functions –
move the functionality to the data. 2.
Spores

25. Function-Passing
Two concepts:
(illustrated) Model
the
1. Stationary, immutable data. Silos
(for a lack of a
better name)
Portable functions –
move the functionality to the data. 2.
Spores

26. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send

27. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send
The handle to a Silo.
(The workhorse.)

28. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send
The handle to a Silo.
def
apply(s1:
Spore,
s2:
Spore):
SiloRef[T]

29. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send
The handle to a Silo.
def
apply(s1:
Spore,
s2:
Spore):
SiloRef[T]
Ta k e s t w o s p o r e s :
LAZY!
framework logic (combinator), e.g. map
user/application-provided argument function
Defers application of fn to silo, returns SiloRef
with info for later materialization of silo.

30. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send
The handle to a Silo.
def
apply(s1:
Spore,
s2:
Spore):
SiloRef[T]
def
send():
Future[T]

31. Function-Passing
Model
the
(illustrated)
Silo[T]
T
Silos.
WHAT ARE THEY?
SiloRef[T]
def
apply
def
send
The handle to a Silo.
def
apply(s1:
Spore,
s2:
Spore):
SiloRef[T]
Sends info for function application
and silo materialization to remote node
EAGER!
def
send():
Future[T]
Asynchronous/nonblocking data transfer to
local machine (via Future)

32. Function-Passing
Model
the
Silo[T]
(illustrated)
SiloRef[T]
T
Machine 1 Machine 2

33. Function-Passing
Model
the
Silo[T]
(illustrated)
SiloRef[T]
λ
T T⇒S
Machine 1 Machine 2

34. Function-Passing
Model
the
Silo[T]
(illustrated)
SiloRef[T]
λ
T
)
SiloRef[S]
Machine 1 Machine 2

35. Function-Passing
Model
the
Silo[T]
(illustrated)
SiloRef[T]
λ
T
)
SiloRef[S]
Silo[S] )
S
Machine 1 Machine 2

36. Function-Passing
Silo
Model
the
(illustrated)

37. Function-Passing
Silo
Model
the
Silo
Silo
Machine 1
(illustrated)

38. Function-Passing
Silo
Model
the
Silo
Silo
Machine 1
(illustrated)
Silo
Silo
Silo
Machine 2

39. Function-Passing
Model
the
Two concepts:
(illustrated)
1. Stationary, immutable data.
Silos
(for a lack of a
better name)
Portable functions –
move the functionality to the data. 2.
Spores

40. What do spores look like?
Basic usage:
val
s
=
spore
{
val
h
=
helper
(x:
Int)
=>
{
val
result
=
x
+
"
"
+
h.toString
println("The
result
is:
"
+
result)
}
}
a sequence of local value (val) declarations
only (the “spore header”), and 1
THE BODY OF A SPORE CONSISTS OF 2 PARTS
2 a closure
http://docs.scala-lang.org/sips/pending/spores.html

41. A Spore
Guarantees...
(vsclosures)
1. All captured variables are declared in
the spore header, or using capture
2. The initializers of captured variables
are executed once, upon creation of
the spore
3. References to captured variables do
not change during the spore’s execution
http://docs.scala-lang.org/sips/pending/spores.html

42. Spores&
Closures
Evaluation semantics:
Remove the spore marker, and the code
behaves as before
spores & closures are related:
You can write a full function literal and pass
it to something that expects a spore.
(Of course, only if the function literal
satisfies the spore rules.)
http://docs.scala-lang.org/sips/pending/spores.html

43. Function-Passing
Model
the
(illustrated)
Spores.
Benefits:
environment (captured variables) is
declared explicitly, and fixed at spore creation time.
can statically ensure that everything captured is
serializable

44. Function-Passing
Model
the
(illustrated)
14
Spores.
Benefits:
6SRUHV $ 7SH%DVHG )RXQGDWLRQ IRU ORVXUHV LQ WKH
$JH RI RQFXUUHQF DQG 'LVWULEXWLRQ
+HDWKHU 0LOOHU 3KLOLSS +DOOHU1 DQG 0DUWLQ 2GHUVN
(3)/ DQG 7SHVDIH ,QF1
environment (captured ’Š‹Ž‹’’ŜŠƒŽŽ‡”ɒ–›’‡•ƒˆ‡Ŝ…‘variables) 1
DQG is
declared ƇŠ‡ƒ–Š‡”Ŝ‹ŽŽ‡”ř ƒ”–‹Ŝ‘†‡”•›ƈɒ‡’ˆŽŜ…Š explicitly, and fixed at spore creation time.
can statically ensure that everything captured is
serializable
$EVWUDFW )XQFWLRQDO SURJUDPPLQJ )3

45. LV UHJXODUO WRXWHG DV WKH ZD IRUZDUG
IRU EULQJLQJ SDUDOOHO FRQFXUUHQW DQG GLVWULEXWHG SURJUDPPLQJ WR WKH PDLQVWUHDP
7KH SRSXODULW RI WKH UDWLRQDOH EHKLQG WKLV YLHZSRLQW KDV HYHQ OHG WR D QXPEHU RI
REMHFWRULHQWHG 22

46. SURJUDPPLQJ ODQJXDJHV RXWVLGH WKH 6PDOOWDON WUDGLWLRQ DGRSW
LQJ IXQFWLRQDO IHDWXUHV VXFK DV ODPEGDV DQG WKHUHE IXQFWLRQ FORVXUHV +RZHYHU
GHVSLWH WKLV HVWDEOLVKHG YLHZSRLQW RI )3 DV DQ HQDEOHU UHOLDEO GLVWULEXWLQJ IXQF
WLRQ FORVXUHV RYHU D QHWZRUN RU XVLQJ WKHP LQ FRQFXUUHQW HQYLURQPHQWV QRQHWKH
OHVV UHPDLQV D FKDOOHQJH DFURVV )3 DQG 22 ODQJXDJHV 7KLV SDSHU WDNHV D VWHS WR
ZDUGV PRUH SULQFLSOHG GLVWULEXWHG DQG FRQFXUUHQW SURJUDPPLQJ E LQWURGXFLQJ D
QHZ FORVXUHOLNH DEVWUDFWLRQ DQG WSH VVWHP FDOOHG VSRUHV WKDW FDQ JXDUDQWHH FOR
VXUHV WR EH VHULDOL]DEOH WKUHDGVDIH RU HYHQ KDYH FXVWRP XVHUGHILQHG SURSHUWLHV
UXFLDOO RXU VVWHP LV EDVHG RQ WKH SULQFLSOH RI HQFRGLQJ WSH LQIRUPDWLRQ FRU
UHVSRQGLQJ WR FDSWXUHG YDULDEOHV LQ WKH WSH RI D VSRUH :H SURYH RXU WSH VVWHP
VRXQG LPSOHPHQW RXU DSSURDFK IRU 6FDOD HYDOXDWH LWV SUDFWLFDOLW WKURXJK D VPDOO
HPSLULFDO VWXG DQG VKRZ WKH SRZHU RI WKHVH JXDUDQWHHV WKURXJK D FDVH DQDOVLV
RI UHDOZRUOG GLVWULEXWHG DQG FRQFXUUHQW IUDPHZRUNV WKDW WKLV VDIH IRXQGDWLRQ IRU
FORVXUHV IDFLOLWDWHV
.HZRUGV FORVXUHV IXQFWLRQV GLVWULEXWHG SURJUDPPLQJ FRQFXUUHQW SURJUDP
PLQJ WSH VVWHPV
ECOOP’ A SIP:
http://docs.scala-lang.org/sips/pending/spores.html

47. Ok,
EXAMPLE,
PLEASE.

48. Function-Passing
Model
the
(illustrated)
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
SiloRef[List[Int]]

49. Function-Passing
Model
the
(illustrated)
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood) (Spores)
SiloRef[List[Int]]

50. Function-Passing
Model
the
(illustrated)
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
SiloRef[List[Int]]
.apply

51. Function-Passing
Model
the
(illustrated)
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
SiloRef[List[Int]] SiloRef[List[Int]]
.apply

52. Function-Passing
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
.apply
Model
the
(illustrated)
SiloRef[List[Int]] SiloRef[List[Int]]
.apply

53. Function-Passing
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
map f
.apply
Model
the
(illustrated)
SiloRef[List[Int]] SiloRef[List[Int]]
.apply

54. Function-Passing
Distributed List with operations map and reduce.
SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
Model
SiloRef[List[Int]]
map (_*2)
the
(illustrated)
reduce (_+_)
EXAMPLE:
(This is what would be happening under the hood)
.apply .apply

55. Function-Passing
Distributed List with operations map and reduce.
SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
Model
SiloRef[List[Int]]
map (_*2)
the
(illustrated)
reduce (_+_)
EXAMPLE:
(This is what would be happening under the hood)
.apply .apply .send()

56. Function-Passing
Model
the
(illustrated)
EXAMPLE:
Distributed List with operations map and reduce.
(This is what would be happening under the hood)
SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)

57. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)

58. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1

59. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1
List[Int]
Silo[List[Int]]
Machine 2

60. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1
List[Int]
Silo[List[Int]]
Machine 2

61. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1
List[Int]
Silo[List[Int]]
Machine 2
λ

62. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1
List[Int]
Silo[List[Int]]
Machine 2
Int
Silo[Int]
List[Int]
Silo[List[Int]]
List[Int]
Silo[List[Int]]

63. SiloRef[List[Int]] SiloRef[List[Int]] SiloRef[Int]
map f
.apply
SiloRef[List[Int]]
.apply .send()
map (_*2)
reduce (_+_)
Machine 1
List[Int]
Silo[List[Int]]
Machine 2
Int
Silo[Int]
List[Int]
Silo[List[Int]]
List[Int]
Silo[List[Int]]
Int

64. Ok,
HOW DOES
THISHELP
WITH
FAULT
TOLERANCE?

65. Data in silos easily
reconstructed:
Silos and SiloRefs relate to each other by
means of a persistent data structure
The persistent data structure is based on
the chain of operations to derive the data
of each silo.
Thus, traversing the silo data structures
yields the complete lineage of a silo.
Since the lineage is composed of spores,
it’s serialized. This means it can be
persisted or transferred to other machine.

66. in
SUMMARY,
Data (Silos) managed using persistent data
structure.
All operations, including operations provided by
system builders, are spores – so, serializable!
Taken together:
A lot simpler to build mechanisms for fault tolerance!