It's been a helluva a while since we updated this thing.  Alison and I just moved in to our new abodes and it's looking quite snazzy.  So we are READY for this school year and we hope you are too.  I just wanted to let you guys know that you will probably find us tonight at THE LOT Festival at The Schlafly Tap Room.  The show begins at 4pm with The Monads and end at midnight with So Many Dynamos.  Also it is the last Victoria show.  So basically I don't really know what else you could be doing on a Saturday night. You can check out the schedule, here via A to Z.

MTL is an excellent library for programming with monads. However stacked monad transformers do not inline well and the library is in need of an optimization pass. As a result, it can often impose a performance hit of up to 300% (your code will run up to three times slower).

Err ... I guess having stacked transformers is a Bad Idea for my inner loop. So I set out to improve the situation. On the same wiki page, there is a report of excellent speedups for the continuation-passing-style (CPS) approach (section 2 on the wiki). The idea is that you implement a custom monad manually combining the features you want, in CPS.

The State-threading-ST-Error Monad

Accordingly, following the advice of that same wiki page, I implemented a new monad supporting state threading, errors, and ST actions, all in continuation-passing style:

> {-# LANGUAGE PolymorphicComponents
>             ,MultiParamTypeClasses
>             ,FunctionalDependencies
>             ,FlexibleInstances
>  #-}
>
> import Control.Monad.Error hiding ((>=>), forM_)
> import Control.Monad.ST.Strict
> import Control.Monad.State.Lazy hiding ((>=>), forM_)
> import Control.Monad.MonadST

Performing an ST action requires a kind of lifting.

> dpllST :: ST s a -> SSTErrMonad e st s a
> {-# INLINE dpllST #-}
> dpllST st = SSTErrMonad (\k s -> st >>= \x -> k x s)
>

SSTErrMonad e st s a: the error type e, state type st, ST thread
s and result type a.

> newtype SSTErrMonad e st s a =
>     SSTErrMonad { unSSTErrMonad :: forall r. (a -> (st -> ST s (Either e r, st)))
>                               -> (st -> ST s (Either e r, st)) }
>
> instance Monad (SSTErrMonad e st s) where
>     return x = SSTErrMonad ($ x)
>     m >>= f  = bindSSTErrMonad m f
>
> bindSSTErrMonad :: SSTErrMonad e st s a -> (a -> SSTErrMonad e st s b) -> SSTErrMonad e st s b
> {-# INLINE bindSSTErrMonad #-}
> bindSSTErrMonad m f = SSTErrMonad (\k -> unSSTErrMonad m (\a -> unSSTErrMonad (f a) k))
>
> instance MonadState st (SSTErrMonad e st s) where
>     get = SSTErrMonad (\k s -> k s s)
>     put s' = SSTErrMonad (\k _ -> k () s')
>
> instance (Error e) => MonadError e (SSTErrMonad e st s) where
>     throwError err =            -- throw away continuation
>         SSTErrMonad (\_ s -> return (Left err, s))
>     catchError action handler = SSTErrMonad
>         (\k s -> do (x, s')                      case x of
>                       Left error -> unSSTErrMonad (handler error) k s'
>                       Right result -> k result s')

The brilliant thing about this implementation is that the monadic bind operator >>= does no case analysis: only if you explicitly attempt to catch an error do you need to do case analysis. In contrast, the ErrorT implementation does:

instance (Monad m, Error e) => Monad (ErrorT e m) where
    m >>= k  = ErrorT $ do
        a <- runErrorT m
        case a of
            Left  l -> return (Left l)
            Right r -> runErrorT (k r)
    ...

The wiki page argues essentially that function calling (in my monad's >>=) is less expensive than constant case analysis when errors are uncommon. And indeed, in my solver, they are uncommon (outside the inner loop, they are not possible).

Pretty Result Graphs; and, What did I do wrong?

But the result is a letdown:

(Graph produced using a Haskell Chart library, built on top of gtk2hs.)

The graph compares the runtime (in seconds) of the original code, in blue, with the new code, in red, on 52 benchmarks available from SATLIB.

The new monad only improves solving times slightly across my benchmarks. So, possibilities:

• I've implemented the monad incorrectly, which doesn't seem likely since my many tests pass.
• I've implemented the monad correctly but inefficiently.
• The time spent doing case analysis isn't significant compared with function invocation.

If anyone has a suggestion, please post it in the comments. I'll definitely try it out.

P.S. Rest of SSTErrMonad, if you're interested

> -- | @runSSTErrMonad m s@ executes a `SSTErrMonad' action with initial state @s@
> -- until an error occurs or a result is returned.
> runSSTErrMonad :: (Error e) => SSTErrMonad e st s a -> (st -> ST s (Either e a, st))
> runSSTErrMonad m = unSSTErrMonad m (\x s -> return (return x, s))
>
> evalSSTErrMonad :: (Error e) => SSTErrMonad e st s a -> st -> ST s (Either e a)
> evalSSTErrMonad m s = do (result, _)                           return result

Update 17 May 2008, 1549: The graph was on too big a scale because of one point, so I removed the point and now the differences are more manifest.

The video above is a short trailer of the record release party for The Monads, who will release their second album "Ornery" on Big Muddy Records.  Watch it, I'll wait.  From the looks of the clip above, it would appear more bad news lies ahead of the primary calendar for Hillary Clinton (watch the video again if you need an explanation of that). 

If "not even a robot Hillary Clinton" can stop this imminent release, you'll know you'll want to be at Off Broadway on March 28th around 9pm.  But get there early, because the first 50 paying guests will receive a complimentary copy of the CD, and our friends at Big Muddy promise surprises:

"Toenail clippings collected from everyone in the band is a possibility," said Monads' banjo player Jason Matthews. "Maybe even an essay I wrote on the proper way to tree a raccoon. You'll just have to find out for yourself!"

To find that out you'll need to bring $7 and one of them picture identification cards to prove you're over the age of 18.  Getting age checked is just the start of your "Ornery" experience on March 28; alongside the bluegrass-styling of the Monads will be emceed by Clownvis Presley anchored by other Big Muddy favorites the Vultures and Pokey LaFarge.  Yep, see you there.

Enjoy !

I have just released a first version of a library introducing an exception monad in OCaml. More informations here.

Je viens de publier la première version d'une bibliothèque introduisant les monades d'exceptions en OCaml. Plus d'informations ici.

Although they are in descending order of "simpleness", this is the order in which I saw them:
First, read the definition of monads from here (only), and stop. It probably won't make sense.

This excellent post:
You Could Have Invented Monads! (And Maybe You Already Have.)
explains monads with enough examples -- they are a kind of "lift". The definition makes sense now.

That, and Philip Wadler's original paper should suffice.

There are too many monad tutorials, and quoting from Tell us why your language sucks:

So, things I hate about Haskell:

Let's start with the obvious. Monad tutorials. No, not monads. Specifically the tutorials. They're endless, overblown and dear god are they tedious. Further, I've never seen any convincing evidence that they actually help. Read the class definition, write some code, get over the scary name.

[Random interesting stuff:
This post looks at them as "expressions" v/s "commands":
The IO Monad for People who Simply Don't Care

There's also some interesting stuff in the first half of this post.]

Of monads and spacesuits is the famous tutorial that uses spaceships and astronauts to illustrate monads ("spacesuits"), which I thought was clearly overkill, but reading it, it is actually pretty good. But again, I'm unconvinced it would actually help anyone understand monads -- it is only useful after you have been using monads for a while.

In a nutshell, they are the PLT manifestation of a concept from category theory, and abstract away propagation of results and side effects, without actually performing side effects or leaving a pure-functional paradigm. Any attempt at description beyond that point tends to either

• a) get terribly botched*, or
• b) turn into a real category theory explanation, which most people don't have the background to understand easily

and for those reasons I will refrain from attempting further explanation myself. I don't have confidence in my own ability to explain in a non-interactive medium, and I certainly don't have the mathematics background to formalize it.

The internet is littered with tutorials and explanations "in laymen's terms" of what monads are, what they are for, why we care, etc. Every such tutorial I have started (at least a dozen, probably several more - all highly recommended) has either bored me to tears, struck me as completely inane, or simply confused me.

I had decided that I was simply going to have to learn abstract algebra and category theory in order to really get a handle on what they were, until a wonderful post appeared on LtU, linking to one of the earlier papers on monads. The paper, by Philip Wadler, gives not only a clear explanation of what a monad is, but also provides a strong motivation for looking for monads, an approachable description of how they are derived from a practical point of view for use in a type system, and a number of useful, nontrivial examples. Probably one of the most well-written academic papers I've read. You should be familiar with an ML-style type system and notation to understand the examples. Or you need be be good at picking up such things on the fly.

Monads for Functional Programming. Enjoy.

On the one hand, we can remember the play of the virtual/actual couple that Badiou finds so fun to dismantle. On the other, the most important thing is to signify how this term works in this particularly situated part of the text. So, giving Deleuze the benefit of the doubt, we should keep in mind that Deleuze doesn’t use the word virtual anywhere in this passage. Neither does he use the word compossible in this passage, but since he has introduced this term with reference to Leibniz, I think it’s important to stress a point that Deleuze makes at the beginning of the series: there is no such thing as incompatibility between events because such a term can only be used when referring to worlds, individuals, or persons (177). Since the disjunctive synthesis is the basis for the affirmation of the divergent, worlds that actualize events can become incompatible because of the divergent singularities that populate their series; strictly speaking though, “it seems that all events, even contraries, are compatible” (177).

So, simply put, Deleuze’s question is: how is the individual able to “transcend his form and his syntactical link with a world” in order to “attain the universal communication of events” (178). But this is not so simple. Here Deleuze seems to mean the following: if, as quoted above, all events are compatible, then how is any language of the event possible? Before following Deleuze’s argument more closely, we should bring Leibniz back to the center of discussion. Deleuze draws on and explicates Leibniz’s theory of monads through The Logic of Sense, and so it would not be inappropriate here to talk about his theory of monads: all monads “perceive” the world from a distinct perspective and also link up with other monads, causing permutations in the vicinity as they link up--Deleuze continues this discussion in Difference and Repetition in order to explain the ways in which the monads express a differential relation between themselves (47). So, in themselves, monads contain a grain of truth about the world which they inhabit. Each monad must be considered in itself, a part which has a reciprocal relationship with other parts, like a link in a signifying chain, and thus a world is constructed from this double action.

Yet, as Deleuze points out, with the event we cannot refer to a grammar of worlds. Syntactically, the event seems both to insist on its extra-being and also entail a pre-individuality that lacks any true communicability. That’s unless we can bring about counter-actualization. In the sense that I understand it, counter-actualization comes about when an individual considers herself as an event and that event as “another individual grafted onto her” (178). This double affirmation extends to treating other individuals as events and their events as individuals—it is this affirmation that brings events “to the power of the eternal return” (178). The power of the eternal return is what allows for an affirmation of the disjunctive synthesis; in other words, the divergence of two series (individuals with respect to the distance of other individuals/events) is not only affirmative but it necessarily alters the other series by resonating in it and vice versa. It is the conjunction of Leibnizian monads and counter-actualization that allows for Deleuze to talk of a unique Event. It is this unique Event that the univocity of Being is: “if Being is the unique event in which all events communicate with one another, univocity refers both to what occurs and to what is said” (180).

--Taylor Adkins

(c) Fractal Ontology, 2007

First get some Haskell fluff out of the way:

> import Prelude hiding (repeat)
> import Data.Map (toList,fromListWith)
> import Complex
> infixl 7 .*

Now define certain types of vector spaces. The idea is the a W b a is a vector in a space whose basis elements are labelled by objects of type a and where the coefficients are of type p.

> data W b a = W { runW :: [(a,b)] } deriving (Eq,Show,Ord)

This is very similar to standard probability monads except that I've allowed the probabilities to be types other than Float. Now we need a couple of ways to operate on these vectors.

mapW allows the application of a function transforming the probabilities...

> mapW f (W l) = W $ map (\(a,b) -> (a,f b)) l

and fmap applies a function to the basis element labels.

> instance Functor (W b) where

>    fmap f (W a) = W $ map (\(a,p) -> (f a,p)) a

We want our vectors to support addition, multiplication, and actually form a monad. The definition of >>= is similar to that for other probability monads. Note how vector addition just concatenates our lists of probabilities. The problem with this is that if we have a vector like $latex a+2a$ we'd like it to be reduced to $latex 3a$ but in order to do that we need to be able to spot that the two terms $latex a$ and $latex 2a$ both contain multiples of the same vector, and to do that we need the fact that the labels are instances of Eq. Unfortunately we can't do this conveniently in Haskell because of the lack of restricted datatypes and so to collect similar terms we need to use a separate collect function:

> instance Num b => Monad (W b) where
>    return x = W [(x,1)]
>    l >>= f = W $ concatMap (\(W d,p) -> map (\(x,q)->(x,p*q)) d) (runW $ fmap f l)

> a .* b = mapW (a*) b

> instance (Eq a,Show a,Num b) => Num (W b a) where
>     W a + W b = W $ (a ++ b)
>     a - b = a + (-1) .* b
>     _ * _ = error "Num is annoying"
>     abs _ = error "Num is annoying"
>     signum _ = error "Num is annoying"
>     fromInteger a = if a==0 then W [] else error "fromInteger can only take zero argument"

> collect :: (Ord a,Num b) => W b a -> W b a

> collect = W . toList . fromListWith (+) . runW

Now we can specialise to the two monads that interest us:

> type P a = W Float a

> type Q a = W (Complex Float) a

P is the (hopefully familiar if you've read Eric's recent posts) probability monad. But Q allows complex probabilities. This is because quantum mechanics is a lot like probability theory with complex numbers and many of the rules of probability theory carry over.

Suppose we have a (non-quantum macroscopic) coin that we toss. It's state might be described by:

> data Coin = Heads | Tails deriving (Eq,Show,Ord)

> coin1 = 0.5 .* return Heads + 0.5 .* return Tails :: P Coin

Suppose that if Albert sees a coin that is heads up he has a 50% chance of turning it over and if he sees a coin that is tails up he has a 25% chance of turning it over. We can describe Albert like this:

> albert Heads = 0.5 .* return Heads + 0.5 .* return Tails
> albert Tails = 0.25 .* return Heads + 0.75 .* return Tails

We can now ask what happens if Albert sees a coin originally turned up heads n times in a row:

> repeat 0 f = id
> repeat n f = repeat (n-1) f . f> (->-) :: a -> (a -> b) -> b

> g ->- f = f g

> (-><) :: Q a -> (a -> Q b) -> Q b
> g ->< f = g >>= f

> albert1 n = return Heads ->- repeat n (->< albert) ->- collect

Let me explain those new operators. ->- is just function application written from left to right. The > in the middle is intended to suggest the direction of data flow. ->< is just >>= but I've written it this way with the final < intended to suggest the way a function a -> M b 'fans out'. Anyway, apropos of nothing else, notice how Albert approaches a steady state as n gets larger.

Quantum mechanics works similarly but with the following twist. When we come to observe the state of a quantum system it undergoes the following radical change:

> observe :: Ord a => Q a -> P a

> observe = W . map (\(a,w) -> (a,magnitude (w*w))) . runW . collect

Ie. the quantum state becomes an ordinary probabilistic one. This is called wavefunction collapse. Before collapse, the complex weights are called 'amplitudes' rather than probabilities. The business of physicists is largely about determining what these amplitudes are. For example, the well known Schrödinger equations is a lot like a kind of probabilistic diffusion, like a random walk, except with complex probabilities instead of amplitudes. (That's why so many physicists have been hired into finance firms in recent years - stocks follow a random walk which has formal similarities to quantum physics.)

The rules of quantum mechanics are a bit like those of probability theory. In probability theory the sum of the probabilites must add to one. In addition, any process (like albert) must act in such a way that if the input sum of probabilities is one, then so is the output. This means that probabilistic process are stochastic. In quantum mechanics the sum of the squares of the magnitudes of the amplitudes must be one. Such a state is called 'normalised'. All processes must be such that normalised inputs go to normalised outputs. Such processes are called unitary ones.

There's a curious subtlety present in quantum mechanics. In classical probability theory you need to have the sum of the probabilities of your different events to sum to one. But it's no good having events like "die turns up 1", "die turns up 2", "die turns up even" at the same time. "die turns up even" includes "die turns up 2". So you always need to work with a mutually exclusive set of events. In quantum mechanics it can be pretty tricky to figure out what the mutually exclusive events are. For example, when considering the spin of an electron, there are no more mutually exclusive events beyond "spin up" and "spin down". You might think "what about spin left?". That's just a mixture of spin up and spin down - and that fact is highly non-trivial and non-obvious. But I don't want to discuss that now and it won't affect the kinds of things I'm considering below.

So here's an example of a quantum process a bit like albert above. For any angle $latex \theta$, rotate turns a boolean state into a mixture of boolean states. For $latex \theta=0$ it just leaves the state unchanged and for $latex \theta=\pi$ it inverts the state so it corresponds to the function Not. But for $latex \theta=\pi/2$ it does something really neat: it is a kind of square root of Not. Let's see it in action:

> rotate :: Float -> Bool -> Q Bool
> rotate theta True = let theta' = theta :+ 0
>   in cos (theta'/2) .* return True - sin (theta'/2) .* return False

> rotate theta False = let theta' = theta :+ 0
>   in cos (theta'/2) .* return False + sin (theta'/2) .* return True

> snot = rotate (pi/2)

> repeatM n f = repeat n (>>= f)

> snot1 n = return True ->- repeatM n snot ->- observe

We can test it by running snot1 2 to see that two applications take you to where you started but that snot1 1 gives you a 50/50 chance of finding True or False. Nothing like this is possible with classical probability theory and it can only happen because complex numbers can 'cancel each other out'. This is what is known as 'destructive interference'. In classical probability theory you only get constructive interference because probabilities are always positive real numbers. (Note that repeatM is just a monadic version of repeat - we could have used it to simplify albert1 above so there's nothing specifically quantum about it.)

Now for two more combinators:

> (=>=) :: P a -> (a -> b) -> P b
> g =>= f = fmap f g> (=><) :: P (Q a) -> (a -> Q b) -> P (Q b)
> g =>< f = fmap (>>= f) g

The first just uses fmap to apply the function. I'm using the = sign as a convention that the function is to be applied not at the top level but one level down within the datastructure. The second is simply a monadic version of the first. The reason we need the latter is that we're going to have systems that have both kinds of uncertainty - classical probabilistic uncertainty as well as quantum uncertainty. We'll also want to use the fact that P is a monad to convert doubly uncertain events to singly uncertain ones. That's what join does:

> join :: P (P a) -> P a
> join = (>>= id)

OK, that's enough ground work. Let's investigate a physical process that can be studied in the lab: the Quantum Zeno effect, otherwise known as the fact that a watched pot never boils. First an example related to snot1:

> zeno1 n = return True ->- repeatM n (rotate (pi/fromInteger n)) ->- collect ->- observe

The idea is that we 'rotate' our system through an angle $latex \pi/n$ but we do so in n stages. The fact that we do it in n stages makes no difference, we get the same result as doing it in one go. The slight complication is this: suppose we start with a probabilistic state of type P a. If we let it evolve quantum mechanically it'll turn into something of type P (Q a). On observation we get something of type P (P a). We need join to get a single probability distribution of type P a. The join is nothing mysterious, it just combines the outcome of two successive probabilistic processes into one using the usual laws of probability.

But here's a variation on that theme. Now we carry out n stages, but after each one we observe the system causing wavefunction collapse:

> zeno2 n = return True ->- repeat n (
>     \x -> x =>= return =>< rotate (pi/fromInteger n) =>= observe ->- join
>     ) ->- collect

Notice what happens. In the former case we flipped the polarity of the input. In this case it remains closer to the original state. The higher we make n the closer it stays to its original state. (Not too high, start with small n. The code suffers from combinatorial explosion.) Here's a paper describing the actual experiment. Who needs all that messing about with sensitive equipment when you have a computer? :-)

A state of the form P (Q a) is called a mixed state. Mixed states can get a bit hairy to deal with as you have this double level of uncertainty. It can get even trickier because you can sometimes observe just part of a quantum system rather than the whole system like oberve does. This inevitably leads mixed states. von Neumann came up with the notion of a density matrix to deal with this, although a P (Q a) works fine too. I also have a hunch there is an elegant way to handle them through an object of type P (Q (Q a)) that will eliminate the whole magnitude squared thing. However, I want to look at the quantum Zeno effect in another way that ultimately allows you deal with mixed states in another way. Unfortunately I don't have time to explain this elimination today, but we can look at the general approach.

In this version I'm going to consider a quantum system that consists of the logical state in the Zeno examples, but also include the state of the observer. Now standard dogma says you can't can't form quantum states out of observers. In other words, you can't form Q Observer where Observer is the state of the observer. It says you can only form P Observer. Whatever. I'm going to represent an experimenter using a list that representing the sequence of measurements they have made. Represent the complete system by a pair of type ([Bool],Bool). The first element of the pair is the experimenter's memory and the second element is the state of the boolean variable being studied. When our experimenter makes a measurement of the boolean variable, its value is simply prepended to his or her memory:

> zeno3 n = return ([],True) ->- repeatM n (
>    \(m,s) -> do
>     s' <- rotate (pi/fromInteger n) s
>     return (s:m,s')
>    ) ->- observe =>= snd ->- collect

Note how we now delay the final observation until the end when we observe both the experimenter and the poor boolean being experimented on. We want to know the probabilities for the final boolean state so we apply snd so as to discard the state of the observer's memory. Note how we get the same result as zeno2. (Note no mixed state, just an expanded quantum state that collapses to a classical probabilistic state.)

There's an interesting philosophical implication in this. If we model the environment (in this case the experimenter is part of that environment) as part of a quantum system, we don't need all the intermediate wavefunction collapses, just the final one at the end. So are the intermediate collapses real or not? The interaction with the environment is known as decoherence and some hope that wavefunction collapse can be explained away in terms of it.

Anyway, time for you to go and do something down-to-earth like gardening. Me, I'm washing the kitchen floor...

typedef struct {
  char *string;
  int value;
} WriterInt;

WriterInt returnWriter(int i)
{
  WriterInt r;
  r.string = "";
  r.value = i;
  return r;
}

WriterInt bind(WriterInt (*f)(int),WriterInt x)
{
  WriterInt y = f(x.value);
  WriterInt z;
  z.value = y.value;
  int len = strlen(x.string)+strlen(y.string);
  z.string = malloc(len+1);
  strcpy(z.string,x.string);
  strcat(z.string,y.string);
  return z;
}

WriterInt print(int i)
{
  WriterInt x;
  x.string = malloc(32);
  x.value = sprintf(x.string,"%d\n",i);
  return x;
}

WriterInt printplus_bad(int i)
{
  WriterInt x = print(i);
  return print(x.value); /* cheating! */
}

WriterInt printplus(int i)
{
  WriterInt x = print(i);
  return bind(print,x);
}

This time, instead of printing, we build up a string as a side effect. printplus() is implemented exactly as before, without knowledge of how to handle side effects, and yet it correctly handles strings returned as a side effect and concatenates them together. The magic is bind() which allows a function expecting an int input to be applied to a WriterInt.

I'm hoping that programmers of languages such as C can now begin to see the pattern shared by these examples.

Anyway, this is all just stalling for time while I try to get my quantum computation code working.