Haskell Reader monad and argument passing

user_652528 0
Viewed 205

I was following this tutorial https://blog.ssanj.net/posts/2014-09-23-A-Simple-Reader-Monad-Example.html

It has tree functions that is embarrassing to me

tom :: Reader String String
tom = do
  env <- ask
  return (env ++ " This is tom.")

jerry :: Reader String String
jerry = do
  env <- ask
  return (env ++ " This is Jerry.")

tomAndJerry :: Reader String String
tomAndJerry = do
   t <- tom
   j <- jerry
   return (t ++ "\n" ++ j)

runJerryRun :: String
runJerryRun  = (runReader tomAndJerry) "Who is this?"

These functions receive no arguments but still they access the reader monad, what magic is happening here? What is the intuition behind this?

I reader monad a kind of global?

haskell
2 Answers

Each of the first two functions returns its own instance of a Reader monad. Then, you can compose them together (in the third function).

For the sake of the argument, let's replace Reader with IO and do something similar, with none of these functions receiving any argument:

getIntFromFile :: IO Int
getIntFromFile = do
    x <- readFile "myfile.txt"
    pure $ read x :: Int

getIntFromStdin :: IO Int
getIntFromStdin = do
    x <- getLine
    pure $ read x :: Int

As you can see, both use the IO monad but they don't share anything in common. However, since they both use the IO monad, you can (and that's the beauty of it) compose them together as follows:

-- | the equivalent of your `tomAndJerry` function
main :: IO ()
main = do
    x <- getIntFromFile
    y <- getIntFromStdin
    print $ x + y

This is exactly the same logic at play with the example from the tutorial, except with Reader instead of IO.

user_20911690

I think one important misunderstanding was addressed by Daniel Wagner in a comment. The Reader is (well, wraps) a function, so it does take arguments. In light of this, I guess your final question

I reader monad a kind of global?

has an answer: yes, in the sense that the reader monad gives you a way to pass an immutable state/environment through chained computations; so it kind of reads the same value everytime it's invoked (via ask) along the chain.

Which in the case of your code means that the two asks (or, equivalently, tom and jerry) both read the same environment, represented by the string "Who is this?".

Imho, this becomes a bit clearer by desugaring the dos:

tom :: Reader String String
tom = ask >>= \env -> return (env ++ " This is Tom.")

jerry :: Reader String String
jerry = ask >>= \env -> return (env ++ " This is Jerry.")

tomAndJerry :: Reader String String
tomAndJerry = tom >>= \t -> jerry >>= \j -> return (t ++ "\n" ++ j)

Here >>= expects a function that returns a monad, but you don't have it, you have the "ordinary" function (e.g. \env -> env ++ " This is Tom."), so you have to use return to wrap the result back into the monad. Then instead of using >>= and return . f, why don't we use fmap f, since we only have to apply a function inside the monad?

Which means that we can go further and simplify by using Functor for tom and jerry and Applicative for tomAndJerry.

tom :: Reader String String
tom = fmap (++ " This is Tom.") ask

jerry :: Reader String String
jerry = fmap (++ " This is Jerry.") ask

tomAndJerry :: Reader String String
tomAndJerry = (\t j -> t ++ "\n" ++ j) <$> tom <*> jerry

Both tom and jerry are asking for the environment, and each of them applies a function to it. Then tomAndJerry is just a way of composing them via a binary function, as pointed out in the accepted answer.

By the way, the language server tells me of asks, which allows to write

tom :: Reader String String
tom = asks (++ " This is Tom.")
user_58252940
Related