Three Useful Monads

http://adit.io/posts/2013-06-10-three-useful-monads.html

by timf • 13 years ago

74 28 13 years ago

I'm really not feeling the music with these, if you know what I mean, which is a shame since it seems as though great lengths have been gone to to make it understandable.

Are there other works you can recommend to learn more from?

jamesaguilar2• 13 years ago

Agreed. The writer example was really telling. The whole syntax around using the function changes when you bring the monad into it. Even the placement of the function calls and the data.

wvs2• 13 years ago

"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)

gosub• 13 years ago

If you already know about high order functions and a bit of haskell notation, I suggest chapters 11 and 12 from "Learn You a Haskell for Great Good!" [1]. I think that following the explanation from Functors -> Applicative Functors -> Monoids -> Monads makes it easier to understand where monads come from and what problem they are trying to solve.

[1] http://learnyouahaskell.com/chapters

exDM69• 13 years ago

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.

yummyfajitas• 13 years ago

I wrote one you might find helpful. It explains monads via a helpful real world analogy.

http://www.chrisstucchio.com/blog/2013/write_some_fucking_co...

egonschiele2• 13 years ago

Post author here. If you tell me where you're stumbling, I might be able to fix it.

You could also check out this post by sigfpe, one of my favorite posts on monads: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

dustingetz2• 13 years ago

so these are actually useful; below i link a fleshed out logger monad in a scala webapp. I wrote it because at work (enterprise webapps) we want to be able to send the logs created over the duration of a request down to the client for diagnostics. Singleton loggers (mutable globals) interleave the logs in a threaded context, and worse in async or high availability contexts, and are basically a giant pain in the ass to extract useful data from.

the actual monadic types are:

    type MyLogger[+A] = WriterT[scalaz.Id.Id, List[String], A]
    type IOLogger[V] = EitherT[MyLogger, Throwable, V]

which represents either an exception or a value, alongside the logs that led up to it.

https://github.com/dustingetz/monadic-logging-play/blob/mast...

Forgive me if this code is ugly, this is my first foray into scalaz. The repo contains a complete minimum play app and will run. Also we're hiring in philadelphia.

egonschiele2• 13 years ago

Glad you found the post useful!

tome6• 13 years ago

    half 8 >>= half

It’s not quite half . half $ 8, but it’ll do

but

    half <=< half $ 8

is!

prof_hobart4• 13 years ago

Well, it clearly isn't. It's an improvement, but "<=<" is still quite different from ".". I can see it from here.

I'm sure there's an entirely justifiable reason why the two syntaxes have to be different, but that doesn't stop it being a bit of a pain when it comes to trying to learn the language - I've developed a bunch of side effect-free code, and I want to stick a bit of logging in the middle of one bit to help me see exactly what's going on, and suddenly I seem to need to rewrite half my code to use a very similar, but subtly different syntax.

tome6• 13 years ago

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.

dllthomas2• 13 years ago

What about:

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

    half' = Kleisli half

    ...

    runKleisli (half' . half') 8

dustingetz2• 13 years ago

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...

acomar• 13 years ago

(<=<) 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.

daGrevis• 13 years ago

This makes me want to learn Haskell once again and maybe, if I'm super lucky, understand something! :)

gohrt• 13 years ago

Until monad transformers are easy to use, monads are a one-way street to a dead-end. Monads are so general that being confined to one per function is a total blocker. Yet monad-transformers require far to much mental/organizational overhead.

Three Useful Monads

Related Stories