Monads without pretension (2011)

http://rcrowley.org/2011/09/21/monads.html

by signa11 • 12 years ago

51 57 12 years ago

The whole point about monads is that they provide a uniform interface for working with values that carry some extra context. The genericity of the interface is nice, in that it allows you to write generic monad combinators, but they are only useful because of the context (effects, control flow, etc). If you don't describe any of the implementations, you are missing the point!

The best introduction to monads was written in 2006 (more than eight years ago now) and I don't imagine that a better one will be written in the near future -

http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...

elwell• 12 years ago

If you want video, this is probably worth watching; haven't finished it yet.

https://www.youtube.com/watch?v=ZhuHCtR3xq8

nightski• 12 years ago

Are you sure? There are plenty useful monads which are not effects... In fact the article you linked even says so.

throwaway2837192• 12 years ago

Yeah, I should have written "computational context" not "effects".

Patient0• 12 years ago

One thing that this article and lot of other Monad articles gloss over is the scoping in "do" notation and when using the >>= operator.

The example:

    return 7 >>= (\x -> Writer (x+1,"inc."))
             >>= (\x -> Writer (2*x,"double."))
             >>= (\x -> Writer (x-1,"dec."))

works for this example, but a more accurate representation of how "do" notation is expanded is:

    return 7 >>= (\x -> Writer (x+1,"inc.")
             >>= (\x -> Writer (2*x,"double.")
             >>= (\x -> Writer (x-1,"dec."))))

Note that I've moved the parentheses.

Actually, you can, equivalently, omit the parentheses for the same meaning, because the '->' has very low precedence:

    return 7 >>= \x -> Writer (x+1,"inc.")
             >>= \x -> Writer (2*x,"double.")
             >>= \x -> Writer (x-1,"dec.")

The point is, most times each of subsequent functions need to "see" what was in scope in the earlier functions. Most times, the later monadic actions need information that is pulled out of the monad in previous actions.

For example, consider the following:

    main = putStrLn "Enter your first name" >>=
       \_ -> getLine >>=
       \first -> putStrLn "Enter your last name" >>=
       \_ -> getLine >>=
       \last -> putStrLn ("Hello " ++ first ++ " " ++ last ++ ".")

The last monadic action needs both "first" and "last" to both be in scope. This only works because of the way that it is implicitly parenthesized.

Until I "got" this, I was very confused by most of the Monad examples I found.

Here's an article I wrote about the IO monad which also makes this point: https://github.com/Patient0/IOMonad

jerf3• 12 years ago

I wrote this up, "So You Want To Write A Monad Tutorial in Not-Haskell": http://www.jerf.org/iri/post/2928 It focuses on all the things I've seen people miss about "monads" when they try to write an implementation in another language after the third time I saw someone claim they'd implemented "monads" in Javascript using method chaining, which I do not believe to be possible in part because of the issue you point out, which is that the scope builds up as you go.

It is perfectly reasonable to also read this as the list of elements of monadery that even tutorials written in Haskell tend to miss or fail to explain.

louthy• 12 years ago

Your C# IO monad could really benefit from using LINQ (I know you mention it at the end). If you're interested in a full set of C# monads (including a fully implemented IO monad) check my csharp-monad library [0]

[0] https://github.com/louthy/csharp-monad

jfarmer• 12 years ago

The best introduction to monads that I've read is the original paper that discussed them in the context of functional programming: http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...

ufo• 12 years ago

On the same vein, SPJ's "Tacking the Awkward Squad" is also a great old paper, and focuses more on impure effects than Wadler's

chriswarbo3• 12 years ago

It's not even about the effects, really. It's simpler to think of Monad as an interface for manipulating encapsulated data in a way which keeps it encapsulated.

The simplest way to encapsulate data is to wrap it using a constructor which we keep private to our module:

    module M1 (Encap(), val1, val2)
    data Encap a = mkEncap a

    val1 :: Encap Int
    val1 = mkEncap 5

    val2 :: Encap Int
    val2 = mkEncap 10

Other modules importing M1 get access to the Encap type, val1 and val2 but not the mkEncap constructor. They can use val1 and val2 as-is, but they can't construct new Encap values or destruct existing Encap values to get at their contents. The problem is, there's not much we can do with this interface.

One way we can make this more useful is being able to apply some function to an encapsulated value. That's what Functor is for, so we can add this to M1:

    instance Functor Encap where
      fmap f (mkEncap x) = mkEncap (f x)

Now users of M1 can transform encapsulated values without being able to break the encapsulation. For example:

    val1Plus7 :: Encap Int
    val1Plus7 = fmap (+7) val1

    val2Str :: Encap String
    val2Str = fmap show val2

We're still pretty limited though, since there's no way to combine encapsulated values into new encapsulated values, or to encapsulate our own values. That's what Applicative provides, by letting us construct encapsulated values without gaining the ability to destruct them, and by allowing encapsulated functions to be applied to encapsulated values (since functions are closures, this lets us gather up encapsulated values and combine them arbitrarily):

    instance Applicative Encap where
      pure x = mkEncap x
      (mkEncap f) <*> (mkEncap x) = mkEncap (f x)

Now users of M1 can encapsulate and combine values, like this:

    -- val1 + val2
    val1PlusVal2 :: Encap Int
    val1PlusVal2 = fmap (+) val1 <*> val2

    -- New encapsulated string
    val3 :: Encap String
    val3 = pure "Hello world"

    -- val3 repeated val1 times
    val3Repeated :: Encap String
    val3Repeated = fmap rep val1 <*> val3
                   where rep n _ | n <= 0 = ""
                         rep n s          = s ++ rep (n-1) s

This is quite a powerful interface, but one thing we can't do is `collapse` double-encapsulated values into single-encapsulated values. That's what Monad provides:

    join :: Encap (Encap a) -> Encap a
    join (mkEncap (mkEncap x)) = mkEncap x

An alternative, but equivalent, definition is to allow calls to encapsulation-producing functions without encapsulating their result. Haskell's Monad is defined this way:

    instance Monad Encap where
      (>>=) :: Encap a -> (a -> Encap b) -> Encap b
      (mkEncap x) >>= f = f x

These kind of encapsulated values turns out to hold effects without breaking the language, and these interfaces turn out to be powerful enough for general computation.

agumonkey• 12 years ago

I like to rename encapsulation as invariant these days. List monad will ensure you have a list of a.

physPop2• 12 years ago

This is a wonderful explanation, thank you!

jberryman• 12 years ago

These kind of encapsulated values turns out to hold effects without breaking the language

I wonder if you're hand-waving a bit here. To me "encapsulated values" describes Identity or Maybe, but really doesn't work (IMO) for e.g. State or IO where bind is composition.

pedrow• 12 years ago

For those like me who find it hard to think outside the imperative programming box, Eric Lippert's series of articles is good.

http://ericlippert.com/2013/02/21/monads-part-one/

A lot of Monad articles like to explain 'what' without first establishing 'why' (IMHO)

mjburgess2• 12 years ago

Monads have so little pretension these days, you'd think they were the salt of the earth. Working classes, for working people.

chriswarbo3• 12 years ago

Monads were pretentious in the '90s. The pretention switched over to Arrows in the '00s and to Algebraic Effects in the '10s ;)

mjburgess2• 12 years ago

Yeah, Arrows is my "next thing".

bkeroack2• 12 years ago

Total nitpick, but it annoys me when people implement something in Python but use ancient syntax.

  return '<M a: %s>' % self.a

Should be:

  return '<M a: {}>'.format(self.a)

And:

  class M(object):

Should be:

  class M:

etc.

jonhohle• 12 years ago

I can see why you might want the second change (discarding superfluous information), but string formatting looks better to me in the first case: it's more terse, and embeds type information in the format string using a well known and understood convention.

Why do you prefer the explicit method call over an operator?

physPop2• 12 years ago

% format is deprecated in the python spec.

bkeroack2• 12 years ago

It's arguable, but operator overloading should only be used (if at all) when there is conceptual symmetry between the standard and overloaded usage (eg, adding two datetime objects with '+').

I can't think of any way that taking the modulo of two strings logically results in interpolation. If anything, it should do something like return the original string with all instances of the argument removed. It's just simpler to not support it at all and use the standard .format() method.

There's also the fact that it's deprecated, of course. :)

illicium• 12 years ago

   class M(object):

is a new-style class in Python 2.x, in which it's the correct syntax: https://docs.python.org/2/glossary.html#term-new-style-class

It's different in Python 3 but that doesn't matter because Python 3 is largely irrelevant.

lelf• 12 years ago

This article can confuse people even more.

This is what monad is (read: interface with two functions):

  class Monad m where
    (>>=)  :: m a → (a → m b) → m b
    return :: a → m a

Read: function >>= of arguments M[a] and (fun from a to M[b]) that returns M[b]. You can probably write it somehow in MyPy annotations.

(It's actually different in haskell, doesn't matter)

The author however just implemented one instance of Monad: Identity (the most trivial). And called it a Monad. And then semi-checked laws on one value.

ksherlock• 12 years ago

Do haskell people realize that using haskell describe monads isn't actually helpful?

orbifold2• 12 years ago

Well you could explain them in terms of category theory as an endofunctor T: C -> C, together with two natural transformations eta : 1 -> T and mu : T^2 -> T, that satisfy a number of axioms. The Haskell definition encodes a special case, where the underlying "category" is "Hask", whose objects are Haskell types and morphisms are Haskell terms. Of course this is strictly speaking not a category, but it is close enough.

In mathematics monads usually arise as adjunctions between two functors, for example beginning with a set of elements, you can consider the free monoid generated by it and forget the group structure, this gives you a much larger set. If you did this operation on a set of characters, you would get the set of all strings of those characters, eta would in this case be the operation that given a character in the character set gives you the corresponding string of length one and mu would concatenate two strings.

dons• 12 years ago

Psuedocode then.

Given a type `m` and a type `a` a monad provides functions with types:

    bind : m a → (a → m b) → m b
    wrap : a → m a

tel3• 12 years ago

You need a language which enables generalization. Sadly, most computer languages lack good facilities for this. Human language works, though:

A monad is some parametric type, T, along with two functions called (in Haskell anyway) "return" and "bind". Return "injects" values into the type taking values of type A to values of type T(A). Bind transforms values of type T(A) into values of type T(B) using a function like A -> T(B).

Then these two functions must follow a few rules.

That's a monad. The Haskell fragment above describes the signatures of those functions, notes how they relate to the parametric type, and also produces a facility for overloading `return` and `(>>=)` ("bind") and even working with them when lacking a concrete choice of type `T`.

louisdefunes• 12 years ago

Is it me or the title is spelled wrongly? Shouldn't it be "pretention"?

bhauer• 12 years ago

According to Wiktionary, you are using an older form of "pretension."

http://en.wiktionary.org/wiki/pretention

kazinator• 12 years ago

The following may help some fellow Lisp-heads understand some aspects of monads:

http://www.kylheku.com/cgit/lisp-snippets/tree/monads.lisp

Monads are developed starting with CLOS, then wrapping macros around them for doing monadic comprehensions. Finally, a monad-defining macro is introduced which generates the class and methods from a succinct syntax, and is used to write several monads, including a state transformer monad.

ddellacosta• 12 years ago

What is the point of implementing monads in Python? I thought the point of monads was that they provide a mechanism for introducing side effects gracefully into a pure language (like, say, Haskell) while still allowing for type safety, per correspondences between category theory and type theory. Python is not strictly typed and makes side effects pretty easy, if I recall from the last time I wrote Python.

Seriously, what is this constant obsession with monads that has infected the programmers?

Why not be obsessed with, say, functors? I can then make statements like, "A functor is a wrapper. Anyone who tells you otherwise is being obtuse" and be just as correct, and sound just as smart.

wanders off grumbling to himself...

zak_mc_kracken• 12 years ago

Monads are not just about effects: encoding effects in the type system is just one of the benefits.

Monads are mostly about enabling composition between operations returning different types.

freyrs34• 12 years ago

I thought the point of monads was that they provide a mechanism for introducing side effects gracefully into a pure language

That's roughly a description of the IO monad, which is a specific monad. The IO monad is really a degenerate case, and most monads ( List, Cont, Maybe, Writer, State, ... ) have nothing to do with effects.

Half the problem of talking about monads is that in their full generality they're really just a description of a trivial algebraic structure that doesn't really impart much intuition. Monads just get a lot of press because they're one of the simplest examples of a structure that can't be compressed easily in terms of common experience. There's nothing I can point to in our our everyday experience and say "monad" is like this.

elclanrs• 12 years ago

In dynamic languages I don't see the need to create a Monad interface. I'd create classes/objects and simply use instances of those objects. As long as they conform to the desired interface, and you can check their relationships, then it should work; and use monkey-patching if necessary, embracing the dynamic nature of the language. I don't think it is possible to fully translate Haskell examples without the types, but you can adapt the ideas to other languages and get very similar functionality, in JavaScript for example:

    class Maybe {
      constructor(value) {
        if (value != null) {
          return new Just(value)
        }
        return new Nothing()
      }
      bind(f) {
        if (this instanceof Just) {
          return f(this.value)
        }
        return new Nothing()
      }
    }

    class Just extends Maybe {
      constructor(value) {
        this.value = value
      }
      toString() {
        return `<Just ${this.value}>`
      }
    }

    class Nothing extends Maybe {
      constructor() {
        this.value = null
      }
      toString() {
        return '<Nothing>'
      }
    }

    var result = Maybe(2).bind(x => {
      return Maybe(3).bind(y => {
        return Maybe(x + y)
      })
    })

    console.log(result.toString()) // <Just 5>

Monads without pretension (2011)

Related Stories