Saturday, February 14, 2009

The state monad gives an elegant way to thread state information through Haskell code. Unfortunately it has an annoying limitation: the state must have the same type throughout the monadic expression. In this post I want to look at how to fix this. Unfortunately, fixing State means it's no longer a monad, but we'll discover a new abstraction that replaces monads. And then we can look at what else this abstraction is good for. The cool bit is that we have to write virtually no new code, and we'll even coax the compiler into doing the hard work of figuring out what the new abstraction should be.

This is all based on an idea that has been invented by a bunch of people independently, although in slightly different forms. I'm being chiefly guided by the paper Parameterized Notions of Computation.

The problem with the state monad is that it is defined by

newtype State s a = State { runState :: s -> (a, s) }

The state going into and out of one of these values is the same, s. We can't vary the type of the state as we pass through our code. But that's really easy to fix, just define:

Problem solved! Except that this definition of State doesn't give us a monad and so we lose the benefits of having an interface shared by many monads. Is there a new more appropriate abstraction we can use? Rather than scratch our heads over it, we can just ask ghci to tell us what's going on.

It's a lot like the usual Monad class except that we're now parameterising uses of this class with a pair of types. Our new >>= operator also has a compatibility condition on it. We can think of an element of m s1 s2 as having a 'tail' and 'head' living in s1 and s2 respectively. In order to use >>= we require the head of the first argument to match the tail given by the second argument.

We didn't really design this class, we just used what ghci told us. Will it turn out to be a useful abstraction?

First a category theoretical aside: in this post I talked about how monads were really a kind of abstract monoid. Well ParameterisedMonad is a kind of abstract category. If we were to implement join for this class it would play a role analogous to composition of arrows in a category. In a monoid you can multiply any old elements together to get a new element. In a category, you can't multiply two arrows together unless the tail of the second matches the head of the first.

Now we can generalise the writer monad to a ParameterisedMonad. But there's a twist: every monoid gives rise to a writer. This time we'll find that every category gives rise to a ParameterisedMonad. Here's the definition. Again, it was lifted straight out of the source for the usual Writer monad. The main change is replacing mempty and mappend with id and flip (.).

It's just like the usual Writer monad except that the type of the 'written' data may change. I'll borrow an example (modified a bit) from the paper. Define some type safe stack machine operations that are guaranteed not to blow your stack:

I guess there's one last thing I have to find. The mother of all parameterised monads. Again, we lift code from the ghc libraries, this time from Control.Monad.Cont. I just tweak the definition ever so slightly. Normally when you hand a continuation to an element of the Cont type it gives you back an element of the continuation's range. We allow the return of any type. This time the implementations of return and (>>=) remain completely unchanged:

So what's going on here? The implementations of these instances require almost trivial changes to the original monads, or in two cases no changes at all apart from the type signature. I have my opinion: Haskell programmers have been using the wrong type class all along. In each case the type signature for return and >>= was too strict and so the functionality was being unnecessarily shackled. By writing the code without a signature, ghci tells us what the correct signature should have been all along. I think it might just possibly be time to consider making ParameterisedMonad as important as Monad to Haskell programming. At the very least, do-notation needs to be adapted to support ParameterisedMonad.

Update: You *can* use do-notation with ParameterisedMonad if you use the NoImplicitPrelude flag.

25 comments:

Nice observation. Certainly, one major reason why parameterized monads are so attractive is exactly because of the easy upgrade path. Anybody who is comfortable writing monadic code can get started very easily, and allow the typechecker to do the heavy mental lifting for them.

Dan, have you tried to use do-notation with this definition of Parameterised Monads ? If so, what was the problem? Since GHC supports rebindable syntax, do-notation should just work when throwing in a NoImplicitPrelude pragma.

This is related to a (wilder) notion of parameterised monads that Edward Kmett gave some time ago.

I agree. I always wanted monads to be more flexible, but as not so experienced Haskell programmer I thought it is something wrong with me since hackers of Haskell would have seen it a long time ago, wouldn't they? I feel relieved (a little bit ^^). Thank you sigfpe!

Just to note that some Haskell programmers were using this extended notion of ParametrisedMonad even before the do-notation was standardised. For instance, back in 1994-5, Niklas Röjemo used this idiom extensively inside the nhc12 and nhc13 compilers. See here for evidence.

GHC does support do-notation for parameterised monads. With GHC 6.10 (at least) you merely need to use {-# LANGUAGE NoImplicitPrelude #-}and GHC will resolve do-notation to use whatever is in scope for (>>=), (>>) and "return". Parameterised monads are also used in Oleg et al's lightweight static resources paper.

GHC supports do-notation for parameterized monads just fine, as it turns out.

I tried to write some code here to show you how to do it but Blogger doesn't allow me to use the proper tags when commenting so it will just look like crap. Instead here is a link to my blog which shows how to do it.

Augustss: My experience has been both. Sometimes you do get impenetrable error messages; often because some definition you got wrong a page or two of code ago actually does typecheck, whereas it wouldn't have previously.

I quickly learned to frequently use ghci to infer the most general type of new definitions. If the type appeared to be right, I'd copy and paste it into my code, if it was obviously wrong, I'd try again. When problems arose, sometimes it took a fair bit of mental effort to figure out exactly what they were.

There is definitely higher type overhead, at least in the short run. But it puts the type system to better work _for you_, among other compelling advantages.

A category object in Set consists of:- two sets O and M (objects and morphisms)- a function i:O -> M (picks out the identity morphism)- two functions s,t:M -> O (source and target)- a function o:X -> M (composition), where X is a set equipped with two functions i,j:X -> M such that s o i = t o j (that is, it's the set of composable pairs and i,j pick out the first or second element)such that the usual relations hold.

Category objects can be defined in any category with pairwise pullbacks:

A "parametrized monad" consists of- two sets O, M (where the elements of O are categories and the elements of M are functors between them)- a function i:O -> M (picking out the identity functor on each category)- two functions s,t:M -> O (source and target of the functors)- a function o:X -> M (composition of functors)

But this is just a subcategory of Cat! What's going on? Just as a monoid is a one-object category, a monoidal category is a one-object 2-category. The generalization you describe moves from the monoidal category End(C) to a 2-category with more objects. So the real term you want isn't "parameterized monad", it's "sub-2-category of Cat".

A different generalization would be to consider a category object in End(C):

Haven't digested all of your comment yet. But briefly, a category object in End(C) is exactly what I'm thinking of. But I haven't expanded out the full definition myself to ensure all of the maps are exactly what they need to be.

So you have a different functor from C to C for each pair (s1, s2) in S. However, you also forbid composition of such functors unless the types match, so the functors aren't really from C to C, they're from s1 x C to s2 x C.

This means you can't possibly be describing a category object in End(C). You have a 2-category whose objects are copies of C indexed by elements of S, functors between the categories, and natural morphisms between the functors.

It's a lovely construction, and well illustrated, just not the one you might have thought you were getting.

I still haven't got around to thinking for myself about what this construction is from a category theoretical perspective. End(C) was just a guess based on ordinary monads being monoids. I'll have to return to this when I have a moment.

This does not represent the value of the state variable inside the type system; rather it allows the type of state variable to vary over the course of the computation.

If you can imagine an example where you want to store two possible types, say either an integer or a string, in the state variable, then one way to do it is to use State (Either Integer String) a. If you know whether the state variable is a string or an integer based solely on where you are in the computation, you can use the parameterized state monad in this post, and avoid the use of Either.