11/16/2016

CategorytheorypatternsinScala

Search

Category theory patterns in Scala

Recent Posts

Posted by Martin Zapletal on Fri, Apr 3, 2015

Event sourced microservices

Find me on:

This week in #Scala (14/11/2016)

This week in #DevOps
(08/11/2016)
This week in #Scala (07/11/2016)

Category theory concepts are often mentioned when discussing functional programming. From my
experience however they are quite difficult to grasp and understand for people without functional
programming background. I have read some articles explaining that this should not be true, because object
oriented programming introduces many concepts as well (think objects, classes, inheritance, method
override etc.). From my experience though these OO concepts and design patterns are much simpler to
understand. Maybe because they have some resemblance with real world objects, maybe because they are
often taught early at universities and used in many companies and maybe also because functional
programming and category theory in particular are closer to mathematics, theory and are overall more
formal.I am often told that these concepts are difficult to understand and the whole area has a very steep
learning curve. Most of the available resources are very formal and do not help much to overcome the initial
resistance which makes people to become frustrated and avoid functional programming. One of our goals is
to support the functional programming community and help beginners overcome the initial difficulties. On
the other hand it is important to understand that these are mathematical concepts and therefore should be
precisely formally defined and used and there may be no simple shortcut. We may present some good
examples, but we should not omit important properties that would invalidate mathematical correctness.
In practice they however server the same purpose as the design patterns. You may not need to know them
and you can use the paradigm without them, but they allow the programmer to spot common patterns and
apply existing abstract solution. With regards to functional design patterns I recommend having a look at
this presentation [1], [2] and obviously this already classic book [3].
Here we will only focus on some concepts such as idempotent, commutativity, associativity, monoid, functor
or monad that are commonly used in functional programming practice and I believe they can be quite
simple to grasp if explained correctly. I also understand some people will not appreciate the reduced
abstraction level, because it reduces the generality of the concept, but I would argue it may be important at
least for the first attempt to understand.This post will not be about correct (flatMap!) or incorrectuse of
monads(if(option.isEmpty) ...) in code, but rather a more general explanation of certain category theory
concepts. I suggest to check the following articleswhich discuss similar topics[4],[5],[6]or[7]if you don't
mind a bit of Haskell.

This week in #DevOps

(01/11/2016)

Posts by Topic
Scala (319)
Akka (276)
DevOps (125)
Docker (107)
AWS (104)
see all

Posts by Author
Jan Machacek (248)
Petr Zapletal (119)
Laura Bria (100)
Chris Cundill (67)
Mark Harrison (36)
see all

Subscribe to Email Updates

First Name*

Last Name*

Category theory
Category theory is a mathematical approach to the study of algebraic structure that has become an
important tool in theoretical computing science, particularly for semantics-based research [8].For
introduction to category theory see for example [9]or[10]. For category theory implemented in Scala have a
look at[11]or[12].
Firstly let's define some of the basic notions of Category theory. Since these are well known I will only try to
simply explain those that are directly required further in the text and avoid otherwise important notions
such as isomorphism, product and sum, initial and terminal objects, natural transformation and others.

Email*

Notification Frequency*
Daily

Weekly

Monthly

Subscribe

Category
Category is an algebra of functions with composition as the main operation. Category consists of objects
(denoted A, B, C, ..) and morphisms (also arrows or functions denoted a, b, c, ...). A morphism with domain A
and codomain B is denoted A -> B (can with generality loss be viewed as function from A to B). Given
morphisms f: A -> B and g: B -> C morphism composition g o f: A -> C (g after f, considering an argument x
gives function call g(f(x))). Also for each object in
http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

a category there exists a identity morphism I : A -> A which

1/9

11/16/2016

CategorytheorypatternsinScala

gives function call g(f(x))). Also for each object in a category there exists a identity morphism IA: A -> A which
simply outputs its input. This scenario can be visualised as

Category also holds two laws:

(1) Identity law (for f: A ->B thenIBo f = f, f o IA = f)
(2) associative law (for f: A -> B, g: B -> C, h: C -> D then h o (g o f) = (h o g) o f = A -> D).
To simplify, consider object I representing integers. Then addition of 0 can be the identity (I -> I which
returns the very same result from the domain). That by itself would be a correct category. We can further
add for example another morphism I -> I called addOne which for its domain (e.g. 5) returns another integer
in the codomain incremented by 1 (6). Both objects and morphisms are general concepts so they can
represent anything from sets to people and functions on them.

Idempotence
First, let's have a look at idempotence. An idempotent is an arrow a : A -> A in a category that satisfies

a2 = a
It simply means that if we apply the same function multiple times the result will always be the same. When
f(x) = y = f(f(x)). Idempotence attribute is used in programming to describe actions that do not have side
effects and their repeated application does not change the result. Consider for example category C
representing all characters in the alphabet with one arrow C -> C called toUpper which for each domain
character returns the capitalised character (e.g. a -> A). Notice that repeated application of this function will
allways return the same result (e.g. a -> A -> A -> A) which makes it idempotent. In category theory terms
this scenario would look like in the picture below. Also notice the direct resemblance with function
definitions (e.g. toUpper: C -> C is a function from C to C. In this case C stands for Char or maybe String type
but generally the constructs we define in category theory are more abstract).

Let's check idempotence in Scala. Function testing idempotence of a function could look like this

1
2
3
4
5
6
7
8
9
10
11
12

defisIdempotent[T](op:T=>T,input:T)={
//a
vala=op

//aoa==a^2.
//Anotheroptionwouldbea(a(input)writtensimplyasop(op(input))
//Noteopisafunctionsowedon'thavetodoop_composeop_
vala2=opcomposeop

//Checkifidempotencelawholds
a(input)==a2(input)
}

Notice how our op: T => T clearly corresponds to less general toUpper: C -> C in category theory example
above. Also Scala's compose() method lets us define composition very similarly as we would have in
category theory. a2 is just a o a or a(a(x)). And if we try to check idempotence of some functions, the result is
as expected. While toUpperCase() is idempotent, addFive() is not (simply because addFive(5) yields result 10
and addFive(addFive(5)) would be 15).

1
2
3

deftoUpper(s:String)=stoUpperCase
defaddFive(i:Int)=i+5

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

2/9

11/16/2016

CategorytheorypatternsinScala

4
5

assert(isIdempotent(toUpper,"IdEmPoTeNcE"))
assert(!isIdempotent(addFive,0))

Idempotence is also useful at a higher level of abstraction. Consider for example HTTP PUT operation or
update of a field in database with value 5. It also has large importance in distributed systems where
idempotent operations ensure correct result even if the client sends duplicate requests. For example with
idempotence attribute a exactly once message delivery semantics is reduced to much less expensive at
least once delivery [13] or transactions may be avoided in certain scenarios [14].

Commutativity
Commutative law says that

x+y=y+x
where + is an operation (does not have to be addition). It simply means that the order of operation is not
important. If we define the commutative law in Scala, it could look like the code below.

1
2

defisCommutative[T](op:(T,T)=>T,x:T,y:T)=
op(x,y)==op(y,x)

And let's check some functions for commutativity. We can see that addition on integers is commutative, but
string concatenation is not (because "HelloWorld" != "WorldHello").

1
2

assert(isCommutative[Int](_+_,4,5))
assert(!isCommutative[String](_+_,"Hello","World"))

Similarly to idempotence commutativity may play an important role in a distributed system. Consider for
example some operation that mutates shared state. In that scenario some kind of transactions or lock is
needed to ensure correct result after all operations are applied. If however the operations are commutative
we can avoid the need for transactions completely and thus significantly reducing the overhead.
Commutativy and idempotence and other laws can be combined to achieve very elegant advantage in
certain scenarios [15], [16].

Associativity
Similarly to commutativity, associativity should be a well known concept to everyone. The associative law
says that

(x * y) * z = x * (y * z)
where * is an operation. If operation is associative (and the above law is meant) it does not matter which
operation is applied first and the result will always be the same. The importance of this is obvious in
mathematics. But the property is very important for example in parallel computing. Consider you have a
large scale computation where the data is distributed to multiple machines (or threads, ...). Let's say we
want to add 4 numbers - a, b, c and d where a and b libe on one machine and c and d on another. If the
operation is associative, we can easily just compute the result of a + b on one machine and c + d on the
other and only then return the results and combine them together as visualised below.

1
2
3
4
5

a+b+c+d
\/\/
(a+b)(c+d)
\/
((a+b)+(c+d))

In this example it does not make much sense, but imagine you have large amount of data on many nodes.
In that case the efficiency of the approach is important. This roughly corresponds to the reduce phase of
MapReduce parallelization approach [17] or reduce() method in Spark [18]. Associativity works with
functions of two parameters of the same type so it can be defined as

1
2

defisAssociative[T](op:(T,T)=>T,x:T,y:T,z:T)=
op(op(x,y),z)==op(x,op(y,z))

And we can see that addition on integers is associative,

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

but division of doubles certainly is not.

3/9

11/16/2016

CategorytheorypatternsinScala

And we can see that addition on integers is associative, but division of doubles certainly is not.

1
2

assert(isAssociative[Int](_+_,1,2,3))
assert(!isAssociative[Double](_/_,1,2,3))

In category theory we could define associativity using the below diagram which commutes [19]. Essentially
we start in the left top corner (S x S x S) where x denotes product in category theory which can be used to
represent function of multiple variables. Say our S x S x S is for example 2 * 3 * 4 where * is multiplication.
Then we apply opperation on the left pair (6 * 4) or right pair (2 * 12) and follow the arrow to the right or
down respectively. After the second operation application the result in the bottom right corner is the same
(24) regardless which path we decided to use. Notice close similarity with the code snippet above and
evaluation order.

Idempotence, commutativity and associativity are concepts that describe certain attributes of some class of
operations. I have deliberately used them as widely understood examples. When we understand what they
mean and how they can be used for our advantage we may start noticing patterns and areas where they can
be applied. It is exactly the same with the category theory concepts we will discuss next. They define certain
abstract structures with certain attributes and if we learn to spot and apply them in a real world we may
gain a lot with regards to elegance, structure or efficiency. In case you are interested in other properties
used in distributed systems to reduce control overhead check CRDTs [20] or higher level focused [21]or[22].

Monoid
A category with one object is called a monoid. Very simple and clear definition using previously defined
attributes of a category. But for better understanding I will also add standard algebraic definition (though it
describes the same concept) and some examples. Monoid is an algebraic structure with single binary
associative operation and an identity element [23],[24], or more formally a structure (M, e, *) where M is a
set, e M is an identity element and * is a function M x M -> M such that the following conditions hold for
each m, n, pM.

(1) m * e = m
(2) e * m = m
(3) (m * n) * p = m* (n * p)
As an example consider M as integers, e as 1 and * operation of multiplication. Then all the above rules are
satisfied, because 5 * 1 = 5, 1 * 5 = 5 and (3 * 4) * 5 = 3 * (4 * 5). Or M again as integers, e as 0 and *
operation of addition. The rules again are satisfied. The monoid visualised in category theory would look like
this [25].

This may look terrifying, but it is actually quite straightforward. is the product we mentioned earlier
(function of more variables) and the first image just represents monoid laws (1) and (2) and the second
image law (3), just with different naming convention. You can follow the diagram using exactly the same
approach as was described above.
Where to use monoids? Anytime you require an associativity and a zero (identity) element. A typical example
is the reduce() method and its variations (fold, foldLeft, foldRight, reduce). They all reduce a monad (usually
a collection of values) into a single value by applying an associative function on an element and result of the
application on previous elements. The first element (starting point, zero) of the function is monoid's identity.
Scala's reduce() method takes two parameters, but Scalaz takes directly instance of monoid. A good
discussion of usages of Monoids is presented in the aforementioned[4]. A practicalexample are
Spark'saccumulators [26]. It is an add only data structure which can thanks to its properties be efficiently
supported in parallel. Notice especially the zero and addInPlace methods which clearly resemble a monoid.
For monoid code in Scala I will borrow some snippets from Scalaz [11]. I will omit large parts of the original
code to only focus on what we discuss here. I would recommend checking the code on github directly, very
educational.

1
2

traitMonoid[F]extendsSemigroup[F]{self=>

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

4/9

11/16/2016

CategorytheorypatternsinScala

3
4
5
6
7
8
9

defzero:F

traitMonoidLawextendsSemigroupLaw{
defleftIdentity(a:F)(implicitF:Equal[F])=F.equal(a,append(zero,a))
defrightIdentity(a:F)(implicitF:Equal[F])=F.equal(a,append(a,zero))
}
}

The laws again clearly coincide with what we defined above. You may have noticed this definition misses the
associative operation we mentioned. This is because monoid extends Semigroup which already defines that
and only adds the zero (identity). For completeness let's see how Semigroup is defined.

1
2
3
4
5
6
7
8
9

traitSemigroup[F]{self=>

defappend(f1:F,f2:=>F):F

traitSemigroupLaw{
defassociative(f1:F,f2:F,f3:F)(implicitF:Equal[F]):Boolean=
F.equal(append(f1,append(f2,f3)),append(append(f1,f2),f3))
}
}

Again notice this is essentially a one to one correspondence to associativity as we defined it earlier.To create
a concrete instance of monoid you can then extend the trait or use the instance() method.

1
2
3
4
5
6
7

definstance[A](f:(A,=>A)=>A,z:A):Monoid[A]=
newMonoid[A]{
defzero=z
defappend(f1:A,f2:=>A):A=f(f1,f2)
}
}

Functor
Understanding functors in terms of category theory may be a bit more tricky. This is because category
theory describes abstract structures that are naturally hierarchical. Functor is very similar to morphisms as
we described them before (functions). The major difference is that it is a morphism between categories
(sometimes called a structure preserving map) instead of objects. This time, consider A and B to be
categories. Then functor F consists of functions

satisfying

Fobj = objA -> objB (function from objects of A to objects of B)

FA1,A2 = (A1 -> A2) -> (F(A1) -> F(A2)) (function from morphisms of A to morphisms of B)

F(IA) = IFA
F(b o a) = F(b) o F(a)
Such scenario with three objects in categories A and B is captured in the below image.

Simply it can be seen as a mapping of objects and

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

morphisms of one category to objects and morphisms of

5/9

11/16/2016

CategorytheorypatternsinScala

Simply it can be seen as a mapping of objects and morphisms of one category to objects and morphisms of
another, where identities and composition are preserved. Then categories as objects and functors as
morphisms form a category which catisfies the category laws - an identity functor exists and functor
composition is possible. Many constructions are functorial and can be extended from arrows to functors. For
example given morphism A -> B we can define functor Ff: F(A) -> F(B).[9]presents a nice example
wheregiven any set X we can construct a new set Stack(X), the set of all stacks of X. This suggests that it may
be possible to extend Stack to a functorStack : Sets -> Sets.To do this we need to define Stack on functions;
that is, to define Stack(f): Stack(X) -- Stack(Y), for each function f : X -> Y. The definition would be:

Stack(f) : Stack(X) -> Stack(Y)where for empty stack we get empty stack otherwise the morphism is defined
as x1x2...xn -> f(x1)f(x2)f(x3). Those of you with functional programming background can see clear
resemblance. A function X -> Y was lifted to a function Stack[X] -> Stack[Y] which applies f to each element
of the Stack which is exactly what map() function does in Scala and fmap() does in Haskell.
Note however the functor domain and codomain do not necessarily have to contain the same number of
objects and arrows (still needs to satisfy the rules though!). Functor mapping all objects from category A to
one object of category B and all morphisms from A to an identity arrow of that one object in B is completely
correct (called constant functor).
Programmers usually say that functor is anything you can map over, i.e. it has a map() method defined. It
obviously has to follow some rules. In Scalaz, Functor is defines as follows

traitFunctor[F[_]]extendsInvariantFunctor[F]{self=>
defmap[A,B](fa:F[A])(f:A=>B):F[B]
}

1
2
3
4

Which is exactly the functor as we defined in category theory terms above. If lifts function f: A => B to
function F: F[A] => F[B]. Now in the context of the previous example, consider the following code snippet.
Let's see some examples. First, let's define a function T => String which simply for any type T returns its
string representation.
deftoString[T](i:T):String=i.toString

We can now use the functor map() method defined above to lift the method to F[T] => F[String] where F can
be for example a List or an Option (so using the concrete types it would be List[Int] => List[String] in the first
example below).
List(1,2,3).map(toString)
Set(true,false).map(toString)
Option("HelloWorld").map(toString)
Future(Person("Bob",25)).map(toString)

1
2
3
4

Monad
A monad is a monoid in the category of endofunctors [27]. Oh, and an applicative functor (as well as a
functor) [28].This may sound terrifying, but the actual use of the monad concept in code is not that difficult
and it provides great benefits.
In Scalaz, monad is defined as follows.

1
2
3
4
5
6
7
8
9
10
11

traitMonad[F[_]]extendsApplicative[F]withBind[F]{self=>

overridedefmap[A,B](fa:F[A])(f:A=>B)=bind(fa)(a=>point(f(a)))

traitMonadLawextendsApplicativeLawwithBindLaw{
/**Lifted`point`isanoop.*/
defrightIdentity[A](a:F[A])(implicitFA:Equal[F[A]]):Boolean=FA.equal(bind(a)(point(_:A)),a)
/**Lifted`f`appliedtopure`a`isjust`f(a)`.*/
defleftIdentity[A,B](a:A,f:A=>F[B])(implicitFB:Equal[F[B]]):Boolean=FB.equal(bind(point(a))(f),f(a))
}
}

First notice it extends Applicative which extends Apply which extends Functor. Therefore the map() method
is available on monad. Applicative also adds method point(), sometimes called pure, unitor applyin
Scalawhich lifts A to F[A] (creates instance of a monad from given value) defined as
http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

6/9

11/16/2016

CategorytheorypatternsinScala

defpoint[A](a:=>A):F[A]

Second it extends Bind which defines method bind(), in Scala known as flatMap, in Haskell as >>=and in C#
as selectMany().

defbind[A,B](fa:F[A])(f:A=>F[B]):F[B]

Monad, Applicative and Bind all have some rules that need to be satisfied. For their description check the
source code of Scalaz or [29].A lot has been written about monads, because it is one of theimportant and
frequently used concepts in functional programming. For further reading see our own great blog
posts[30],[31],[32]or for example[33],[34],[35],[36],[37],[38]or othermore practical and Scala
specific[39],[40]and many, many more. I would strongly recommend to at least learn how to use monads,
because they are very common and their use has significant advantages for your code, such as avoiding null
checks, exceptions, representing asynchronous computations, side effecting I/O, disjunction, state,
dependency injection, validation and many more and importantly also representing the state of the
computation explicitly using types. Just for completeness a simple example of monad usage to avoid loops,
null checks and demonstration use of uniform monad API for different monads and purposes.

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10

defprocess(in:Option[Int]):Option[Double]=
in.flatMap(x=>Option(x+1))
.map(_.toDouble/2)
.filter(_%2==0)

vala=Some(7)//Apply
valb=None

assert(process(a)==Some(4))
assert(process(b)==None)

defprocess(in:Seq[String]):Seq[Char]=
in.flatMap(x=>x.toCharArray)
.map(_.toUpper)
.filter(!Seq('U','E').contains(_))

vala=Seq("queue")//Apply
valb=Seq()

assert(process(a)==Seq('Q'))
assert(process(b)==Seq())

Conclusion
We have tried to cover some of the basic category theory concepts in an understandable way. And hopefuly
this article will help to overcome the initial difficulties and spark some interest in the area. For those who
want to obtain a deeper understanding of this field of mathematics, more reusable concepts and higher
level design patterns as well as their real life usage in code (and you should if you are interested in
functional programming; which again you should be :)) we have provided a number of references and
resources for further reading.

References

[1] http://www.slideshare.net/ScottWlaschin/fp-patterns-ndc-london2014
[2]http://www.ndcvideos.com/#/app/video/2311
[3]http://www.manning.com/bjarnason/
[4]http://www.michael-noll.com/blog/2013/12/02/twitter-algebird-monoid-monad-for-large-scala-data-analytics/
[5]http://blog.jarandaf.com/slides/scalabcn_burritos_110315.pdf
[6]https://hseeberger.wordpress.com/2010/11/25/introduction-to-category-theory-in-scala/
[7]http://en.wikibooks.org/wiki/Haskell/Category_theory
[8] http://www.cs.nott.ac.uk/~gmh/cat.html
[9]http://www.amazon.com/Categories-Computer-Science-Cambridge-Texts/dp/0521422264
http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

7/9

11/16/2016

CategorytheorypatternsinScala

[10]http://www.slideshare.net/kenbot/category-theory-for-beginners
[11]https://github.com/scalaz/scalaz
[12]https://github.com/non/cats
[13]http://research.microsoft.com/apps/pubs/?id=173885
[14]http://devhawk.net/2007/11/09/the-importance-of-idempotence/
[15]http://lostechies.com/jimmybogard/2013/06/06/acid-2-0-in-action/
[16]http://link.springer.com/chapter/10.1007%2F978-3-540-76890-6_34#page-1
[17]http://en.wikipedia.org/wiki/MapReduce
[18]https://spark.apache.org/docs/1.3.0/api/scala/index.html#org.apache.spark.rdd.RDD
[19]http://en.wikipedia.org/wiki/Diagram_%28category_theory%29
[20]http://highscalability.com/blog/2010/12/23/paper-crdts-consistency-without-concurrency-control.html
[21]http://www.bailis.org/papers/ca-vldb2015.pdf
[22]http://www.dainf.cefetpr.br/~tacla/SDII/PracticalUseOfClocks.pdf
[23]http://en.wikipedia.org/wiki/Monoid
[24]http://en.wikiversity.org/wiki/Introduction_to_Category_Theory/Monoids
[25]http://en.wikipedia.org/wiki/Monoid_(category_theory)
[26]http://spark.apache.org/docs/1.3.0/programming-guide.html#accumulators

Software

Innovation

DevOps

Invest

Experience

About us

Careers

Tech Blogs

[27]http://stackoverflow.com/questions/3870088/a-monad-is-just-a-monoid-in-the-category-of-endofunctors-whats-the-problem
[28]https://wiki.haskell.org/What_a_Monad_is_not
[29]http://eed3si9n.com/learning-scalaz/Monad+laws.html
[30]http://www.cakesolutions.net/teamblogs/2012/02/03/scalaz-monads-in-spring
[31]http://www.cakesolutions.net/teamblogs/2012/08/14/either-monad
[32]http://www.cakesolutions.net/blog/teamblogs/2013/12/29/monad-transformers
[33]http://learnyouahaskell.com/a-fistful-of-monads
[34]https://www.haskell.org/tutorial/monads.html
[35]http://en.wikibooks.org/wiki/Haskell/Category_theory
[36]http://en.wikipedia.org/wiki/Monad_(category_theory)
[37]http://homepages.inf.ed.ac.uk/wadler/papers/yow/monads-scala.pdf
[38]http://eed3si9n.com/learning-scalaz-day5
[39]http://scabl.blogspot.co.uk/2013/02/monads-in-scala-1.html
[40]http://debasishg.blogspot.co.uk/2008/03/monads-another-way-to-abstract.html

Topics: Scala, Haskell, Functional programming, Monads, Scalaz, Category theory

Chris Bedford 5/6/2015, 1:01:16 AM

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

8/9

11/16/2016

CategorytheorypatternsinScala

Thanks for the article. The key 'Aha!' for me was understanding that categories correspond to data types in scala.
The fact that a monoid was a category initially threw me because i got confused by the fact the monoid was a
structure that contained a set of elements (together witht h one binary operatory).. Then I realized the monoid
wasn't the set .. but the structure itself.. the set AND the operations. In scala terms .. this would be the data type..
not instances of the type, which were elements of the set. For dummies like me you may wish to point this out.
Anyway, thanks for writing this up. It's helpful.

ReplytoChrisBedford

First Name*

Last Name*

Email*

Comment*

Subscribe to follow-up comments for this post

Typethetext

Software

Innovation

DevOps

Invest

Experience

About us

Careers

Tech Blogs

Privacy&Terms

SubmitComment

Manchester Office

London Office

New York Office

Houldsworth Mill

CodeNode

Cake Solutions INC

Houldsworth Street

10 South Place

33 Irving Place, 3rd Floor

Manchester SK5 6DA

London

New York, NY 10003

0845 617 1200

EC2M 2RB

+1 347 708 1518

[email protected]

[email protected]

Cake Solutions 2016 | Privacy policy | Cookies policy

http://www.cakesolutions.net/teamblogs/categorytheorypatternsinscala

9/9