4

When I compare the binary operations of the Applicative and Monad type class

(<*>) :: Applicative f => f (a -> b) -> f a -> f b
(=<<) :: Monad m       => (a -> m b) -> m a -> m b

two differences become apparent:

  • ap expects a normal, pure function, whereas bind expects a monadic action, which must return a monad of the same type
  • with ap the sequence of actions is determined by the applicative, whereas with bind the monadic action can determine the control flow

So monads give me additional expressive power. However, since they no longer accept normal, pure functions, this expressiveness seems to come at the expense of code reuse.

My conclusion might be somewhat naive or even false, since I have merely little experience with Haskell and monadic computations. Any light in the dark is appreciated!

  • 1
    What do you mean when you say "code-reuse"? Monads and Applicatives are different concepts used in different contexts. While every Monad is also an applicative, using applicatives you can generate more efficient code, such as Parsers for example. – ThreeFx Nov 13 '16 at 12:28
  • Somewhat related: http://stackoverflow.com/questions/7040844/applicatives-compose-monads-dont – danidiaz Nov 13 '16 at 12:38
  • With functors I am able to reuse plain, pure functions in specific computational contexts. With applicatives I am able to reuse plain, pure functions that take values from several contexts of the same applicative. Now I want to reuse plain, pure functions within monadic computations. But `bind` expects a "special" function (which I've called monadic action), which have to return a monad of the same type. Therefore I have the impression that the reuse of pure functions is not the purpose of monads. –  Nov 13 '16 at 13:12
  • 1
    I can't understand the premises. `ap` does not take a function `a -> b`, but `f (a -> b)` which is a different thing. You _can_ use `ap (pure g) ...`, of course, but that's another thing. Further, every monad is an applicative, so if you can make type `T a` into a monad, there's no reason not to make it an applicative as well (indeed, that's now mandatory in recent GHCs ...) Hence, I can not understand this question. – chi Nov 13 '16 at 13:23
  • @chi `f (a -> b)` is a pure function somehow produced in a context. But it is still a pure function. `(a -> m b)` is different, because the mechanism of how a value is produced in a context has been shifted into the function itself. I just have a hard time to understand how (a -> m b) is used in an idiomatic way. Since you don't understand my question, I guess I am on the wrong track. –  Nov 13 '16 at 19:37
  • 2
    @ftor (1) An `f (a -> b)` value is not necessarily a *single* pure function in a context -- for instance, consider `[(2*), (3+)] :: Num a => [a -> a]`, or `Nothing :: Maybe (String -> String)`. While it does consist of (zero or more) plain functions in a context, calling it a "pure function" leads to confusion. (2) A key feature of `(=<<) :: Monad m => (a -> m b) -> m a -> m b` is that the context of `m b` depends on the `a` value(s). In `putStrLn =<< getLine`, the string that shows up in your screen is the very same one that you typed in the terminal. `fmap` and `(<*>)` can't do that. – duplode Nov 13 '16 at 20:02

3 Answers3

8

If you have pure function g :: a -> b you can make it be either Applicative version by

pure g :: Applicative f => f (a -> b)

or Monadish by

pure . g :: Applicative f => a -> f b

So you don't lose any code reuse in your sense.

Shersh
  • 9,019
  • 3
  • 33
  • 61
1

Code reuse is only an advantage if you can reuse code to do what you actually want.

GHCi> putStrLn =<< getLine
Sulfur
Sulfur
GHCi>

Here, (=<<) picks the String result produced in an IO context by getLine and feeds it to putStrLn, which then prints said result.

GHCi> :t getLine
getLine :: IO String
GHCi> :t putStrLn
putStrLn :: String -> IO ()
GHCi> :t putStrLn =<< getLine
putStrLn =<< getLine :: IO ()

Now, in the type of fmap/(<$>)...

GHCi> :t (<$>)
(<$>) :: Functor f => (a -> b) -> f a -> f b

... it is perfectly possible for b to be IO (), and therefore nothing stops us from using putStrLn with it. However...

GHCi> putStrLn <$> getLine
Sulfur
GHCi>

... nothing will be printed.

GHCi> :t putStrLn <$> getLine
putStrLn <$> getLine :: IO (IO ())

Executing an IO (IO ()) action won't execute the inner IO () action. To do that, we need the additional power of Monad, either by replacing (<$>) with (=<<) or, equivalently, by using join on the IO (IO ()) value:

GHCi> :t join
join :: Monad m => m (m a) -> m a
GHCi> join (putStrLn <$> getLine)
Sulfur
Sulfur
GHCi>

Like chi, I also have trouble understanding the premises of your question. You seem to expect that one of Functor, Applicative and Monad will turn out to be better than the others. That is not the case. We can do more things with Applicative than with Functor, and even more with Monad. If you need the additional power, use a suitably powerful class. If not, using a less powerful class will lead to simpler, clearer code and a broader range of available instances.

duplode
  • 33,731
  • 7
  • 79
  • 150
  • I guess my understanding of monads is way too schematic. I just try to get a better sense of how to use (a -> m b) in an idiomatic way. Sorry for the confusion and thanks for your help! –  Nov 13 '16 at 18:53
0

The reason for this question was my too schematic understanding of the relations between the functor, applicative and monad class. I thought it was only about reusing pure functions.

(<*>) essentially says give me an applicative of functions and a bunch of applicatives of values and I will apply them according to my rules.

(=<<) essentially says give me a function (a -> m b) and a monad and I will feed (a -> m b) with the value of the monad and leave it to (a -> m b) to produce and return a transformed value wrapped in the same monad.

Of course, the applicative code will be more concise and better reusable, because the mechanism of how a sequence of actions is executed is defined exclusively within (<*>). However, applicative sequences are also somehow mechanic. So when you want to control the flow of the sequence or the "shape" of the resulting structure, you need the extra power of monads, which leads to more verbose code.

I think this question isn't particularly helpful and if people vote for closing, I would have no problem deleting it.