[Haskell-cafe] Could someone teach me why we use Data.Monoid?
Anton van Straaten
anton at appsolutions.com
Fri Nov 13 12:46:31 EST 2009
Andrew Coppin wrote:
> This is the thing. If we had a class specifically for containers, that
> could be useful. If we had a class specifically for algebras, that could
> be useful. But a class that represents "any possible thing that can
> technically be considered a monoid" seems so absurdly general as to be
> almost useless.
You don't have to look any further than the Writer monad to find an
example of how this kind of abstraction is useful. The Writer monad
uses a monoid to accumulate results. The monoid provided to Writer
could be container-like, like a list; it could be a record whose fields
are updated with each operation; it could be a number whose value
changes with each operation; etc. The point is that it's general: it
can be any value that can be combined with another value of the same
type, using some operation to do that combination.
Sigfpe's article about monoids goes into more detail:
> If you don't know what an operator *does*, being able to
> abstract over it isn't especially helpful...
The author of the Writer monad didn't know, and doesn't need to care,
what the operator does. To him, being able to abstract over this
unknown operator was not only helpful, but critical: without that, you'd
need a different type of Writer for different types of accumulator.
Indeed, we see that kind of thing regularly in lesser languages, where
e.g. a logging class might require an instance of a container class to
log to, so that if you want to do an accumulation that doesn't involve a
container, you're out of luck. Or perhaps you get clever and implement
a container class that actually wraps some non-container like value, so
that "appending" to the container updates the value. Now you've
reinvented monoids, and proved that the author of the logging class
*did* need to be able to abstract over an unknown operator, but just
didn't realize it.
More information about the Haskell-Cafe