Three Useful Monads

"half 8 >>= half" might look a lot different from "half . half $ 8", but they're actually identical in underlying structure! The monad version is just using the wrong operator for visual comparison.

(.) composes two functions[1] but (>>=) composes a monad value with a monad function[2]. It'd be nice if we had an operator to compose two monad functions instead.

We can define that operator in terms of (>>=): "g <=< f = \x -> f x >>= g". You can check that the types work out[3]. Notice the great similarity to (.). (It's because they're both categorical composition operators of functions.)

Now we can write "half <=< half $ 8" and everything's dandy.

  [1]: (.) :: (b -> c) -> (a -> b) -> (a -> c)
  [2]: (>>=) :: m a -> (a -> m b) -> m b
  [3]: (<=<) :: (b -> m c) -> (a -> m b) -> (a -> m c)

There are different kinds of people, some might learn by going the theoretical path you described (functors -> monoids -> monads). I am not one of these people. I learn theory by doing thing in practice.

I recommend starting out with IO and "learning monads" as you go. Too many people think they must "understand" monads first, but this might not be the right way to go depending on the person.

"Guess the number" and other examples from Imperative programming 101 make great exercises.

Granted, it's not exactly the same.

> I seem to need to rewrite half my code to use a very similar, but subtly different syntax.

Half is a massive over exaggeration if you've written it in the right way, i.e. the in the composable manner, preferring (.) and (<=<) over function application and (>>=). However, this I don't know how widely appreciated this style is. It's certainly not taught first in functional programming, unfortunately.

What about:

    import Prelude hiding ((.))
    import Control.Category
    import Control.Arrow

    half' = Kleisli half

    ...

    runKleisli (half' . half') 8

you can also rewrite `half . half $ 8` as `half <=< half $ 8` in the identity monad. So if you aren't sure what monad you need, you can write the code against the identity monad and then change the monad later when you need to add logging.

An example where this shines is writing interpreters. You can write a "calculator" interpreter in identity monad, then add an environment (functions and lexical scope), then add errors, then make the environment mutable, then add continuations and try/catch. The core eval loop does not change as you implement new keywords like 'def' or 'throw'. In an imperative interpreter, each feature is coupled with the interpreter core.

I've done this in python but writing pure code in python is so crappy that it's not even worth sharing. Here is a short blog post though with code samples:

http://www.dustingetz.com/2012/10/02/reader-writer-state-mon...

(<=<) is a generalization of (.), and it's one of a number of historical issues that many Haskellers would like to see resolved, but everyone is afraid to try because it would basically break every single available library (many of which are no longer actively maintained). This is basically a library issue, not a syntax issue. A similar issue is that the Monad typeclass doesn't require a Functor instance, even though it's mathematically necessary. There's a long standing argument over how the Prelude (standard library) should be updated/modified, but there's a lot of bikeshedding going on.