Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

- Présentation Kivy (et projets assoc... by Gabriel Pettier 5248 views
- Why functional why scala by Neville Li 1563 views
- Scala the language matters by Xiaojun REN 544 views
- Introduction to Monads in Scala (2) by stasimus 6562 views
- Thinking functional-in-scala by Knoldus Inc. 1433 views
- Introduction to Option monad in Scala by Jan Krag 9635 views

No Downloads

Total views

1,574

On SlideShare

0

From Embeds

0

Number of Embeds

10

Shares

0

Downloads

35

Comments

0

Likes

5

No embeds

No notes for slide

- 1. Category Theory Theory and Applications for Functional Programming
- 2. Format of Talk 1. Introduce definition from Category Theory 2. Use something from Scala as an example 3. Show it satisfies the definition. 4. Do ^^ until Monad defined 5. Prove that definition given in FP is equivalent to definition given in Category Theory Plus random points about application and practicalities along the way
- 3. Note about foundations ● Category Theory is itself a foundation of mathematics, and strictly speaking you don’t need Set Theory to do Category Theory ● Nevertheless a lot of examples and language used to explain Category Theory is actually borrowed from Set Theory ● I will do the same as it makes things much easier (strictly speaking I’m using the von Neumann–Bernays–Gödel (NBG) set theory Axiomatization, which is a conservative extension of ZFC that allows us to talk about Proper Classes (e.g. Class of all Sets)
- 4. Definition - Category 1. a class ob(C) of objects 2. a class hom(C) of morphisms, or arrows, or maps, between the objects. Each morphism f has a unique source object a and target object b where a and b are in ob(C). We write f: a → b, and we say "f is a morphism from a to b". 3. for every three objects a, b and c, a binary operation hom(a, b) × hom(b, c) → hom(a, c) called composition of morphisms; the composition of f : a → b and g : b → c is written as g ∘ f or gf. (Some authors use "diagrammatic order", writing f;g or fg.) such that the following axioms hold: a. (associativity) if f : a → b, g : b → c and h : c → d then h ∘ (g ∘ f) = (h ∘ g) ∘ f, and b. (identity) for every object x, there exists a morphism 1x : x → x (some authors write idx ) called the identity morphism for x, such that for every morphism f : a → b, we have 1b ∘ f = f = f ∘ 1a .
- 5. Example - Scala S Let the set of Types in Scala be Ob(C) Let the set of 1 param Functions in Scala be hom(C) NOTATION: Methods of a Type A, that return a type B that take no params can be equivalently considered as 1 param functions f: A -> B. Therefore I will interchange method invocation and function application henceforth. Composition o is defined as simply normal function composition, now For any f, g, h (types obv) we have (h o (g o f))(x) = (g o f)(h(x)) = f(g(h(x))) = f((h o g)(x)) = ((h o g) o f)(x) - associativity For any T, id_T : T -> T is defined by for any x is a T, id_T(x) = x, clearly this is an identity
- 6. Definition - Functor
- 7. Example - Parameterized Types Many parameterized types in Scala can be viewed as Functors with their map operation; Let S be the Scala Category, and F: S -> S associate any T in Ob(S) to List[T] in Ob(S) associate any f: A -> B (for any A, B in Ob(S)) to map(f): List[A] -> List[B]. Now for any T in Ob(S) F(id_T)(someList) = someList.map(x => x) = (x => x)(someList) = id_List[T] = id_F[T] - so satisfies identity preservation And it’s obvious that someList.map(f).map(g) = someList.map(g o f), so satisfies composition preservation Practical Point When you write a parameterized type in an API in Scala with a map function, you are telling the API user that map(f).map(g) is the same as map(f o g). So in Scalding, it’s often convenient to chain map operations together for readability, rather than compose the functions - but Scalding is clever, it will compose the functions for you so that your still O(N) not O(2N), O(3N) etc.
- 8. Definition - Natural Transformation .If F and G are functors between the categories C and D, then a natural transformation η from F to G associates to every object X in C a morphism ηX : F(X) → G(X) between objects of D, called the component of η at X, such that for every morphism f : X → Y in C we have:
- 9. Example - Flatten Let F: S -> S and G: S -> S be the Option[Option[ _ ]] Functor and Option[ _ ] Functor respectively. NOTATION: will be sloppy henceforth Let f: X -> Y in Hom(S) So F(f): Option[Option[ X ]] -> Option[Option[ Y ] is .map(_.map(f)) G(f): Option[X] -> Option[Y] is .map(f)
- 10. Example - Flatten - Continued Let N_x be .flatten[x], then flatten is a Natural Transformation: N_Y = flatten[Y]: Option[Option[Y]] -> Option[Y] N_X = flatten[X]: Option[Option[X]] -> Option[X] So N_Y o F(f) = .map(_.map(f)).flatten and G(f) o N_X = .flatten.map(f). Now Some(Some(x)).map(_.map(f)).flatten = Some(Some(x).map(f)).flatten = Some(Some(f(x)).flatten = Some(f(x)) = Some(x).map(f) = Some(Some(x)).flatten.map(f) Note there are many more natural transformations, like if we defined toList on Option. Practical Point Knowing an operation is a natural transformation makes refactoring easier.
- 11. Definition - Monad!!
- 12. Example - Option Monad Let F be the Option Functor, then combined with the flatten natural transformation M we have a monad: For any X in Ob(S) F(M_X) = map(_.flatten) : Option[Option[Option[X]]] -> Option[Option[X]] M_F(X) = M_Option[X] = flatten[Option[X]]: Option[Option[Option[X]]] -> Option[Option[X]] so M_X o F(M_X) = .map(_.flatten).flatten : Option[Option[Option[X]]] -> Option[X] M_X o M_F(X) = .flatten.flatten : Option[Option[Option[X]]] -> Option[X] Let’s check these are equal Some(Some(Some(x))).map(_.flatten).flatten = Some(Some(Some(x)).flatten).flatten = Some(Some(x)).flatten = Some(x) = Some(Some(x)).flatten = Some(Some(Some(x))).flatten.flatten Therefore we have the first coherence condition ...
- 13. Example - Option Monad continued Now our Identity natural transformation will be the Some function, i.e. N_X = Some: X -> Option[X] (which is the same as Id(X) -> Option[X]) so F(N_X) = .map(Some), so M_X o F(N_X) = .map(Some).flatten, which is clearly the identity Functor (other way round - exercise)
- 14. Definition - Monad in FP In functional programming a monadic Type M is simply defined in terms of flatMap, where: For any f: X -> M[Y], g: Y -> M[Z], and any x: M[X] x.flatMap(f).flatMap(g) = x.flatMap(f(_).flatMap(g)) and there exists a neutral element N: X -> M[X], where x.flatMap(N) = x
- 15. Theorem - Equivalence The two previous definitions are equivalent when we make the following substitution .map(f).flatten for flatMap(f) - (*) Proof: .flatten.flatten = .map(_.flatten).flatten - Monad Category Theory => .map(f(_).map(g)).flatten.flatten = .map(f(_).map(g)).map(_.flatten).flatten - by substituting in .map(f(_).map(g)) Now RHS = .map(f(_).map(g).flatten).flatten - by Functor Composition Preservation = .flatMap(f(_).map(g).flatten) - by (*) = .flatMap(f(_).flatMap(g)) - by (*) ...
- 16. Proof continued Now LHS = x.map(f(_)).map(_.map(g)).flatten.flatten - by Functor Composition Preservation = x.map(f).flatten.map(g).flatten - since flatten is a natural transformation (recall earlier slide) = x.flatMap(f).flatMap(g) - by (*) twice. Therefore .flatMap(f(_).flatMap(g)) = .flatMap(f).flatMap(g) It remains to show the identity conditions (exercise)
- 17. Further Reading Monoids - Used in Reduce operations in Map Reduce to parallelize operations that cumulate a single value. E.g. + is a monoid. Covariance and Contravariance - Used in Typing rules for type inference
- 18. Summary of Applications 1. Using Category Theoretic notions in code is a little like a formalization of design patterns 2. When a reader sees a particular notion, they need to use less cognitive resources to comprehend the code by familiarity 3. It’s easier to refactor code due to known equivalences, some of these equivalences are even used by Intellij (and ReSharper for LINQ) for the auto- refactor shortcuts 4. Sometimes APIs allow the user to write readable code, but the resulting compiled code will be in it’s most computationally efficient representation. 5. Compilers use concepts in Category Theory 6. State hiding FP design

No public clipboards found for this slide

Be the first to comment