[Haskell-cafe] Could someone teach me why we use Data.Monoid?

Dan Piponi dpiponi at gmail.com
Sun Nov 15 13:32:43 EST 2009


2009/11/14 Daniel Schüssler <anotheraddress at gmx.de>:
>>  - Product (a,b) and co-product (Either) of monoids
> the coproduct of monoids is actually a bit tricky.

Funny, I was just thinking about that.

I was pondering the article at LTU on Lawvere theories:
http://lambda-the-ultimate.org/node/3235

Essentially the idea is this: monads correspond to algebraic theories
and monad transformers are ways to combine algebraic theories.

But Lawvere theories provide another way to describe algebraic
theories, and hence the things that monads can help with: like side
effects, state and non-determinism.

The advantage of Lawvere theories is there is some nice mathematics
for how to combine them, something that's lacking from monads.

So I just worked through a simple example: combining the Writer monad
with itself. As Lawvere theories there are two ways to combine them:
the product and the sum.

The product corresponds, I think, to the usual monad transformer. This
gives the Writer monad corresponding to the product of monoids.

But the sum gives the Writer monad for the coproduct of monoids. (I
think this is correct, but I'm not 100% sure I totally get Lawvere
theories yet.)

If you think about it, it's a very natural thing to do. If you think
of the Writer monad as being useful to make logs then the coproduct
allows you to interleave two different kinds of logs keeping the
relative order of the entries. The usual monad transformer keeps two
separate logs and so loses the relative ordering information. So it's
actually something you might frequently want in real world code. But I
can't imagine a monad transformer for Writer that would give the
coproduct when combined with another Writer, so I don't think it could
be implemented as such.
--
Dan


More information about the Haskell-Cafe mailing list