Monads and Schroedinger’s cat
Posted by harold at December 2nd, 2007
It seems like everybody and his brother (unless his brother makes web 2.0 sites with rounded corners) is clamoring to use Haskell these days. Mostly because they think it’s 31337, but have no idea how it actually works. This eventually devolves into a discussion of trying to figure out what the heck monads are. Well, I have another explanation, folks. And it involves an analogy.
Think about Schroedinger’s cat in the box. You can’t directly interact with the cat, but if you wanted to feed it, you could put a mouse in the box. And if you wanted to pet it, you couldn’t stick your hand in (’cause you’d be getting information out), but you could make a petting device and stick that in the box.
Well, folks, a monad M is basically a box. Something of type M a is a box with something of type a inside. For example, you could have an M cat where the type cat can have values LiveCat or DeadCat—but from outside the box, you don’t know which it is.
If you want to transform the a to a b, you have to make sure that all the information about the original a thing remain in the box. The only way to do this is to put a function of type a -> b into the box, with the instructions to apply it to the thing inside the box. For example, you might have an M cat and want to apply a function adorn that puts a little hat on the cat, which would have type cat -> (hat, cat). But hold on there! Now you need some help to put that function into the box.
The monad operations, explained elsewhere, are simply syntax for this intuition. The “return” function puts something into a box. The “bind” operation (>>= in Haskell) takes something in a box, and a function, and puts the function into the box and applies it to the thing inside. In Haskell, the function is actually expected to return something already in a box, so we’d have to compose return with our cat-hatting function (return . adorn), making something of type cat -> M (hat, cat). The rest is details.
nice..but i think if you are using the schroedinger’s cat as an analogy, you should also explain what’s and why’s(consequence) we should not interact directly with the contents in the box (in the context of monad in say haskell)
Prakash
I’d argue that what you have here isn’t an analogy, it’s a precise description!
If I is some index set, and we label some basis vectors using the I, and call the vector space generated by this basis V(I), then V is a monad. In a very crude form: in quantum mechanics I is a set of classical states and V(I) is the corresponding set of quantum states. Quantum mechanics forms a monad and what you have given is a verbal description of this. The ‘bind’ operator tells you how to compose operations that convert classical states to quantum states.
Dan Piponi
Great question, Prakash! Let me take a stab at it.
In Schroedinger’s original cat analogy, observing the cat had an effect of determining whether the cat’s state was either dead or alive. Up until the point of observation, the cat had an abstract state: either dead or alive.
The key point here is that simply observing the information inside the box made a change to the state of the world! One of the core assumptions in Haskell is that expressions are referentially transparent: you can always replace a piece of code with the result of its evaluation, and the program will have the same meaning. This is super-handy for things like lazy evaluation, retry on failure, and simply making sure that parts of your program can’t do totally bonkers unexpected things.
So, for example, what do you do if your program needs to perform IO (change the world)? Well, Haskell’s answer is you put all your change requests in a box (compose all your expressions that depend on IO inside the IO monad), and then hand that box off to someone else who will actually open it (the runtime system that calls main in Haskell).
harold
Thanks, this was very clarifying!
Chandler
why don’t I want to look in the box?
Stephan
You don’t want to kill the cat now do you?
buffi