{"id":286,"date":"2007-01-23T15:03:40","date_gmt":"2007-01-23T15:03:40","guid":{"rendered":"http:\/\/scientopia.org\/blogs\/goodmath\/2007\/01\/23\/haskell-a-first-step-into-monads\/"},"modified":"2007-01-23T15:03:40","modified_gmt":"2007-01-23T15:03:40","slug":"haskell-a-first-step-into-monads","status":"publish","type":"post","link":"http:\/\/www.goodmath.org\/blog\/2007\/01\/23\/haskell-a-first-step-into-monads\/","title":{"rendered":"Haskell: A First Step Into Monads"},"content":{"rendered":"

The biggest nightmare for most people learning Haskell is monads<\/em>. Monads are the
\nkey to how you can implement IO, state, parallelism, and sequencing (among numerous other things) in Haskell. The trick is wrapping your head around them.<\/p>\n

<\/p>\n

On the most basic level, they’re actually pretty easy to understand. Think about something like IO in purely functional terms. When you write a function that performs an IO action, what are you really
\ndoing in terms of functions? For the moment, ignore all practical concerns, and just think in the
\npure abstract: what happens when you do an output operation?<\/p>\n

What happens is that you write some data to some entity accessible to the program. In purely
\nfunctional terms, you can think of taking a snapshot of the entire state of stuff accessible to the program<\/em> both before and after the output action. Then the output operation is a function
\nfrom the state before to the state after. In pseudocode:<\/p>\n

\ndata StateOfEverything = ...\nprint :: String -> StateOfEverything -> StateOfEverything\n<\/pre>\n
 Now, suppose you want to perform two IO actions in sequence – like printing “Hello world” by printing “Hello” and then printing “world”. What’s going on there?<\/p>\n
 What’s going on is that you’re chaining<\/em> functions together, so that the state which
\nis the output of one function is the input to another.<\/p>\n
\nprintHelloWorld stateBefore =\nlet stateAfter = print \"Hello\" stateBefore\nin print \" World\" stateAfter\n<\/pre>\n
 Writing things that way – passing the state returned from one statement as a parameter to
\nthe next one – is a pain. It’s messy, hard to read, and generally unpleasant. So why not just
\ndo an abstraction? Just write a combinator<\/em>, for chaining together calls. (A
\ncombinator is a function which takes other functions as parameters for the purpose of combining or modifying them in some way.)<\/p>\n
\nchain :: (x -> x) -> (x -> x) -> x -> x\nchain firstfun secondfun initstate =\nlet nextState = firstfun initstate\nin secondfun nextstate\nprintHello stateBefore =\nprint \"Hello\" stateBefore\nprintWorld stateBefore =\nprint \" World\" stateBefore\nprintHelloWorld stateBefore =\nprintHello `chain` printWorld\n<\/pre>\n
 That’s pretty much what a monad does. There’s a bit more to it – the combinator needs to behave
\nin certain ways – but the central concept is that the monad is a kind of combinator that enables
\nsequential chaining with the transfer of an internal state object between steps. Haskell also
\nprovides some nice syntax in the form of “do<\/code>” expressions and a ton of flexibility in
\nterms of monad parameters – but the most basic thing going on in monad code is that basic chaining of
\na state parameter from call to call in a sequence.<\/p>\n
 Now, let’s look at doing what I just did with “chain”, only do it using the Haskell IO monad:<\/p>\n
\n>printHello ::  IO ()\n>printHello  = print \"Hello \"\n>\n>printWorld ::  IO ()\n>printWorld = print \"World\"\n>\n>printHelloWorld ::  IO ()\n>printHelloWorld  = do\n>                      printHello\n>                      printWorld\n<\/pre>\n
 As you can see, there’s a monad type<\/em> IO<\/code>, which is an object encapsulating
\nthe IO state. You can’t<\/em> see inside of it – the IO state itself is completely hidden, and
\ninaccessible to any code outside of the implementation of the IO monad. But what it does is combine
\nfunctions so that the IO state returned by one operation is passed on to the next in sequence. It’s really just like the chaining operator – but with a really nice syntax, and a lot more flexibility. <\/p>\n
 To see why it’s more flexible, let’s start by breaking down the “do<\/code>” syntax, and see what’s really going on. The do statement in the code example above is equivalent to the following:<\/p>\n
\n>printHelloWorldWithoutDo :: IO ()\n>printHelloWorldWithoutDo = printHello >>= ( x -> printWorld)\n<\/pre>\n
 One of the things that the “do<\/code>” syntax does is expand each expression after the
\nfirst in the do so that the result value of each expression is passed as a parameter to the next. So
\nin addition to just passing the IO state internally, it also allows the programmer to pass their own
\nvalue from one element of the sequence to the next. To see just how flexible that is, let’s take a
\nmoment, and look at the actually type of “>>=<\/code>“.<\/p>\n
\n*Main> :type (>>=)\n(>>=) :: (Monad m) => m a -> (a -> m b) -> m b\n<\/pre>\n
 Let’s piece that apart. First, monads are type-parametric – meaning that, for example, “IO” isn’t a type; “IO x” is a type – an instance value of the IO monad carrying a payload<\/em> value of type x.<\/p>\n
 The monadic sequencing parameter takes two parameters. The first is a monad value with a payload of type “a”. The second is a function which can be chained with the first – so it needs to take a parameter value who type is the type of the payload carried over from the first<\/em> – so it’s a function from a value of type “a” to another monad value – but it doesn’t need to return the
\nsame type as the first<\/em> – it doesn’t need to return an instance of IO a<\/code>. It can return whatever type of payload it wants – so the type of the second parameter is a function from a value of type a, to a monad carrying a value of type b. <\/p>\n
 What this means is that there’s a huge amount of flexibility in how we can pass values
\nbetween steps of a monad! My naive chain operator required everything in a sequence to take and return values of exactly the same type; the actual monadic chaining operator allows each step of a monadic chain to take different types as input, and return different types as output – so long as the value returned by one step matches the parameter type accepted by the next.<\/p>\n
 Let’s take a look at how this value-carrying stuff can actually be really useful – and at the same time, get a look at the other really wonderful thing about Haskell’s do<\/code> syntax.
\nSuppose we want to write the usual follow-on to a hello world program – that is, a program that
\nasks for the users name, and then prints out a hello message using it. Here’s the
\nprogram as a Python function:<\/p>\n
\ndef FancyHello():\nprint \"What is your name?\"\nx = sys.stdin.readLine()\nprint \"Hello \", x\n<\/pre>\n
 How do we do that in Haskell?<\/p>\n
\n>fancyHello :: IO ()\n>fancyHello =\n>    do\n>       print \"What is your name?\"\n>       x        print (concat [\"Hello \", x])\n<\/pre>\n
 In addition to the simple chaining, Haskell do<\/code> statements allow us to bind<\/em>
\nthe payload returned by a step in a monadic sequence to a pattern, and then use the names defined by that pattern throughout the rest of the do<\/code> statement. So, since “getLine<\/code>” has type “IO String<\/code>“, in the body of a “do<\/code>” statement, “getLine<\/code>” can be treated as a function that returns a string – and the result of it can be bound to a variable using the “<-<\/code>” operator.<\/p>\n
 There are a couple of tricks to using monads. Suppose in our fancyHello<\/code> function,
\nwe wanted to return<\/em> the hello string with the users name, instead of printing it. You might<\/em> think that we could do something easy like:<\/p>\n
\nfancyHW :: String\nfancyHW =\ndo\nprint \"What is your name?\"\nx <- getLine\nconcat ["Hello ", x]\n<\/pre>\n
 But if you try to put that through a Haskell compiler, you’ll get a type error. You see, there’s no way out<\/em> of a monad. Once you’re inside a monad, there’s no way out. It’s a closed world. You can’t<\/em> get out of it. So you can’t<\/em> return an input string from the IO monad without the IO state associated with it by the monad. So fancyHW<\/code> can’t return “String<\/code>“; it must return “IO String<\/code>“. Based on that, you might think that
\nthe fix would be to just change the declaration in the code above to:<\/p>\n
\nfancyHW :: IO String\nfancyHW =\ndo\nprint \"What is your name?\"\nx <- getLine\nconcat ["Hello ", x]\n<\/pre>\n
 Again, it doesn’t work. concat<\/code> returns a value of type String<\/code>, not
\na value of type IO String<\/code>. How do we generate a value of type IO String<\/code>? There’s a function return<\/code>, with type (Monad m) => a -> m a<\/code>. What return<\/code> does is wrap a non-monadic value into the appropriate monad type, so that it can be used as an element in a monadic sequence.  So let’s look at the correct version of
\n“fancyHW<\/code>“:<\/p>\n
\n>fancyHW :: IO (String)\n>fancyHW =\n>   do\n>      print \"What is your name?\"\n>      x       return (concat [\"Hello \", x])\n<\/pre>\n
 This works, but it’s actually a bit deceptive. In fact, return<\/code> is a bit deceptive –
\nit makes monadic code read more clearly in some cases, but it can also be very misleading, because it
\ndoes not<\/em> return a value from the “do<\/code>” statement; it just wraps a non-monadic
\ncall, so that it can be enclosed in a monadic sequence. Let’s look at a variation of the above
\nto see why it can be confusing. This is a bit artificial to make it short, but it illustrates the point.<\/p>\n
\n>generateHelloMessage :: String -> String\n>generateHelloMessage name = concat [\"Hello there \", name, \", how are you?\"]\n>\n>fancyTwo :: IO ()\n>fancyTwo = do\n>              print \"What is your  name?\"\n>              x               msg               print msg\n<\/pre>\n
 See, the return<\/code> call isn’t returning<\/em> a value from the do<\/code> statement, it’s just wrapping a non-monadic call so that it can be a participant in a
\nmonadic sequence.<\/p>\n
 This isn’t all there is to know about monads; this is just barely scratching the surface. We’ll go farther with it in the next few posts. We’ll go through some more details of the IO monad,
\nshow a couple of other monad types, how to define your own monad types, and show a wonderful example of monads as glue: you can write YACC-like parser code in Haskell without a parser generator,
\nusing a parser monad!<\/p>\n","protected":false},"excerpt":{"rendered":"
The biggest nightmare for most people learning Haskell is monads. Monads are the key to how you can implement IO, state, parallelism, and sequencing (among numerous other things) in Haskell. The trick is wrapping your head around them.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[89],"tags":[],"class_list":["post-286","post","type-post","status-publish","format-standard","hentry","category-haskell"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p4lzZS-4C","jetpack_sharing_enabled":true,"jetpack_likes_enabled":true,"_links":{"self":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/286","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/comments?post=286"}],"version-history":[{"count":1,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/286\/revisions"}],"predecessor-version":[{"id":3578,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/posts\/286\/revisions\/3578"}],"wp:attachment":[{"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/media?parent=286"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/categories?post=286"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.goodmath.org\/blog\/wp-json\/wp\/v2\/tags?post=286"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}