College Functors, Applicatives

Transcription

1 College Functors, Applicatives Wouter Swierstra with a bit of Jurriaan Hage Utrecht University

2 Contents So far, we have seen monads define a common abstraction over many programming patterns. This kind of abstraction occurs more often in Haskell s libraries. In these slides we discuss: functors applicative functors 2

3 1. Functors 3

4 Functors 1 We are all familiar with map for lists: traversing a list and applying a function to its elements This also makes sense for binary trees, and all kinds of other datatypes A functor generalizes applying a function to the elements of a list to other datatype constructors: class Functor f where fmap :: (a > b) > f a > f b The function fmap says how to traverse f -like-things to adapt values of type a it may contain. 4

5 Maybe example 1 instance Functor Maybe where fmap f (Just x) = Just (f x) fmap f Nothing = Nothing Prelude> fmap ("C:\> " ++) (Just "ls -al") Just "C:\> ls -al" Prelude> fmap (^2) (Just 3) Just 9 Prelude> fmap undefined Nothing Nothing The only content is the a value in the Just, so that is what we change. A Nothing stays a Nothing. 5

6 Tuples examples 1 For tuples we can have instance Functor ((, ) a) where fmap f (x, y) = (x, f y) Functor only allows us to map one type parameter, so we give it (, ) a) (pairs with first component of type a), and can only apply the function to the second component. So, Prelude> fmap (*2) (1,3) (1,6) Is this natural? Maybe not. 6

7 What about our own types 1 data Tree a b = Leaf1 (a, b) Leaf2 (b, a) Bin (Tree a b) b (Tree a b) deriving Show An instance of Functor can only map b values! Think this through when ordering the type arguments. instance Functor (Tree a) where fmap f (Leaf1 p) = Leaf1 (fmap f p) -- On 2nd fmap f (Leaf2 (v, i)) = Leaf2 (f v, i) -- Do NOT use fmap! fmap f (Bin t1 v t2) = Bin (fmap f t1) (f v) (fmap f t2) 7 Prelude> fmap (*2) (Bin (Leaf2 (1, 1 )) 3 (Leaf1 ( 2,2)) Bin (Leaf2 (2, 1 )) 6 (Leaf1 ( 2,4))

8 Alternatively 1 We can decide to only change values in the leaf: instance Functor (Tree a) where fmap f (Leaf1 p) = Leaf1 (fmap f p) fmap f (Leaf2 (v, i)) = Leaf2 (f v, i) fmap f (Bin t1 v t2) = Bin (fmap f t1) v (fmap f t2) -- Note the v for f v Prelude> fmap (*2) (Bin (Leaf2 (1, 1 )) 3 (Leaf1 ( 2,2)) Bin (Leaf2 (2, 1 )) 3 (Leaf1 ( 2,4)) 8

9 Summary 1 Functors are one argument functions applied to things that exist in some context (like a list context) A well-known example is when such a context is a container type, like lists, trees (Tree a was our context), and even maybes. But what if I have two maybes and want to apply a binary function to their contents? Like ( ) (Just 2) (Just 3) to get Just 6. 9

10 Summary 1 Functors are one argument functions applied to things that exist in some context (like a list context) A well-known example is when such a context is a container type, like lists, trees (Tree a was our context), and even maybes. But what if I have two maybes and want to apply a binary function to their contents? Like ( ) (Just 2) (Just 3) to get Just 6. I need an applicative! Prelude> (*) <$> Just 2 <*> Just 3 Just 6 9

11 2. Applicative 10

12 Sequencing IO operations 2 Applicatives lie inbetween Functors and Monads. sequenceio :: [IO a] > IO [a] sequenceio [ ] = return [ ] sequenceio (c : cs) = do x < c xs < sequenceio cs return (x : xs) There is nothing wrong with this code but using do notation may seem like overkill. The variable x isn t used in the second computation, only as part of the result! 11

13 Using ap 2 The ap function defined as follows: ap : Monad m => m (a > b) > m a > m b ap mf mx = do f < mf x < mx return (f x) Using ap we can write: sequenceio :: [IO a] > IO [a] sequenceio [ ] = return [ ] sequenceio (c : cs) = return (:) ap c ap sequenceio cs 12 This works for any monad, not just the IO monad.

14 Evaluating expressions 2 Another example: data Expr v = Var v Val Int Add (Expr v) (Expr v) type Env v = Map v Int eval : Expr v > Env v > Int eval (Var v) env = lookup v env eval (Val i) env = i eval (Add l r) env = (eval l env) + (eval r env) We are passing around an environment that is only really used in the Var branch. 13

15 An applicative alternative 2 const : a > (env > a) const x = a s : (env > a > b) > (env > a) > (env > b) s ef es env = (ef env) (es env) eval : Expr v > Env v > Int eval (Var v) = lookup v eval (Val i) = const i eval (Add l r) env = const (+) s (eval l) s (eval r) The s combinator lets us apply one computation expecting an environment to another. 14

16 Transposing matrices 2 transpose :: [[a]] > [[a]] transpose [ ] = repeat [ ] transpose (xs : xss) = zipwith (:) xs (transpose xss) Can we play the same trick and find a combinator that will apply a list of functions to a list of arguments? zapp : [a > b] > [a] > [b] zapp (f : fs) (x : xs) = (f x) : (zapp fs xs) transpose (xs : xss) = repeat (:) zapp xs zapp transpose xss 15

17 What is the pattern? 2 What do these functions have in common? ap : IO (a > b) > IO a > IO b s : (env > a > b) > (env > a) > (env > b) zapp : [a > b] > [a] > [b] 16

18 Applicative (applicative functors) 2 class (Functor f ) => Applicative f where pure :: a > f a (< >) :: f (a > b) > f a > f b Note that Functor is a superclass of Applicative. As with functors f represents a context, but now the function to be applied is also in that context, e.g., a list. 17

19 Applicative (applicative functors) 2 We can also define map in terms of the applicative operations (traditionally, it is called (<$>): (<$>) :: Functor f => (a > b) > f a > f b How might we define this function? 18

20 Applicative (applicative functors) 2 We can also define map in terms of the applicative operations (traditionally, it is called (<$>): (<$>) :: Functor f => (a > b) > f a > f b How might we define this function? (<$>) f fx = pure f < > fx To apply a (normal) function in a context as an applicative, simply wrap it in a context and use (< >). 18

21 Relating Applicative functors and Monads 2 Every monad can be given an applicative functor interface. instance Monad m => Applicative m where pure :: a > m a pure = return mf < > mx = do f < mf x < mx return (f x) 19 But this may not always be the right choice. For example, we have seen the zippy applicative instance for lists; using the instance arising from the list monad gives very different behaviour! But not every applicative functor is a monad...

22 Monads vs. applicative functors - I 2 (< >) :: (Applicative f ) => f (a > b) > f a > f b (>>=) :: (Monad m) => m a > (a > m b) > m b The arguments to < > are (typically) first-order structures (that may contain higher-order data). Monadic bind is inherently higher order. With monads, subsequent actions can depend on the results of effects: depending on the character the user enters, respond differently. 20

23 Monads vs applicative functors - II 2 There are more Applicative functors than there are monads; but monads are more powerful! If you have an Applicative functor, that s good; having a monad is better. If you need a monad, that s good; only needing an Applicative functor is better. With applicative functors, the structure is statically determined (and can be analyzed or optimized). 21

24 Compare the two 2 How to model an if-then-else statement with monads or applicatives: miffy :: Monad m => m Bool > m a > m a > m a miffy mb m1 m2 = do b < mb if b then m1 else m2 mappy :: Applicative m => m Bool > m a > m a > m a mappy fb f1 f2 = ite <$> fb < > f1 < > f2 where ite b t e = if b then t else e 22 The former only runs m1 or m2, the second may evaluate both, and then chooses which one to return. The strict sequentiality of the monad is missing in the applicative.

25 Composing monads 2 Given two monads m1 and m2, is m1. m2 a monad? data Compose m1 m2 a = Compose (m1 (m2 a)) instance (Monad m1, Monad m2) => Monad (Compose m1 m2) where return :: a > m1 (m2 a) (>>=) :: m1 (m2 a) > (a > m1 (m2 b)) > m1 (m2 b 23 Unfortunately, there is no guarantee that such an instance can be defined. As a result, there has been a great deal of work on monad transformers, that allow complex monads to be assembled from smaller pieces. For applicative functors however...

26 Composing applicative functors 2 For any pair of applicative functors f and g: data Compose f g a = Compose (f (g a)) instance (Applicative f, Applicative g) => Applicative (Compose f g) where pure :: a > f (g a) pure x =... (< >) :: f (g (a > b)) > (f (g a)) > f (g b) fgf < > fgx =... We can define the desired pure and < > operations! This is a guarantee of compositionality. 24

27 Composing applicative functors 2 For any pair of applicative functors f and g: data Compose f g a = Compose (f (g a)) instance (Applicative f, Applicative g) => Applicative (Compose f g) where pure :: a > f (g a) pure x = pure (pure x) (< >) :: f (g (a > b)) > (f (g a)) > f (g b) fgf < > fgx = (pure< >) < > fgf < > fgx We can define the desired pure and < > operations! Intuition: wrapping something into two contexts, is like wrapping it once in a wrapped context. 25 This is a guarantee of compositionality.

28 Imprecise but catchy slogans 2 26

29 Imprecise but catchy slogans 2 Monads are programmable semi-colons! 26

30 Imprecise but catchy slogans 2 Monads are programmable semi-colons! Applicatives are programmable function application! 26

31 Applicative functor laws 2 identity pure id < > u = u composition pure (.) < > u < > v < > w = u < > (v < > w) NB. (< >) is left associative, so u < > v < > w = (u < > v) < > w homomorphism pure f < > pure x = pure (f x) interchange 27 u < > pure x = pure (\ f > f x) < > u

32 To summarise 2 functors: you apply a function to a wrapped value using fmap (or <$>) applicatives: you apply a wrapped function to a wrapped value using < > monads: you apply a function that returns a wrapped value, to a wrapped value using (>>=) (or liftm) 28

33 Why should we care? 2 Functional programmers are addicted to abstraction: as soon as they spot a pattern, they typically want to abstract over it. The type classes we have seen today, such as monads, functors and applicative functors, all capture some common pattern. Using these patterns can save you some boilerplate code. 29

34 Why should we care? 2 Functional programmers are addicted to abstraction: as soon as they spot a pattern, they typically want to abstract over it. The type classes we have seen today, such as monads, functors and applicative functors, all capture some common pattern. Using these patterns can save you some boilerplate code. And understanding these patterns can help guide your design. Think of them as typed design patterns for which support has been added to the language. Is my type a monad? Or is it just applicative? 29