5

After looking up the Control.Monad documentation, I'm confused about this passage:

The above laws imply:

fmap f xs = xs >>= return . f

How do they imply that?

Community
  • 1
  • 1

2 Answers2

8

Control.Applicative says

As a consequence of these laws, the Functor instance for f will satisfy

fmap f x = pure f <*> x

The relationship between Applicative and Monad says

pure = return
(<*>) = ap

ap says

return f `ap` x1 `ap` ... `ap` xn

is equivalent to

liftMn f x1 x2 ... xn

Therefore

fmap f x = pure f <*> x
         = return f `ap` x
         = liftM f x
         = do { v <- x; return (f v) }
         = x >>= return . f
Community
  • 1
  • 1
ephemient
  • 189,938
  • 36
  • 271
  • 385
  • 2
    Well, this just pushes the question down to the `Applicative` level. That is: why is `fmap f x = pure f x` a consequence of the `Applicative` laws? After all, they don't even mention `fmap`! And then to answer that, you need @duplode's observation about parametricity... – Daniel Wagner May 22 '17 at 23:19
7

Functor instances are unique, in the sense that if F is a Functor and you have a function foobar :: (a -> b) -> F a -> F b such that foobar id = id (that is, it follows the first functor law) then foobar = fmap. Now, consider this function:

liftM :: Monad f => (a -> b) -> f a -> f b
liftM f xs = xs >>= return . f

What is liftM id xs, then?

liftM id xs
xs >>= return . id
-- id does nothing, so...
xs >>= return
-- By the second monad law...
xs

liftM id xs = xs; that is, liftM id = id. Therefore, liftM = fmap; or, in other words...

fmap f xs  =  xs >>= return . f

epheriment's answer, which routes through the Applicative laws, is also a valid way of reaching this conclusion.

Community
  • 1
  • 1
duplode
  • 32,686
  • 7
  • 74
  • 141
  • I think the substitutions are more straightforward in my answer but yours expresses more of the intuition for why it *should* be. – ephemient May 22 '17 at 15:53