[Haskell-cafe] Comments from OCaml Hacker Brian Hurt

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Thu Jan 15 17:05:00 EST 2009


On Thu, 2009-01-15 at 16:03 -0500, Andrew Wagner wrote:
> I think perhaps the correct question here is not "how many instances
> of Monoid are there?", but "how many functions are written that can
> use an arbitrary Monoid". E.g., the fact that there are a lot of
> instances of Monad doesn't make it useful. There are a lot of
> instances of Monad because it's useful to have instances of Monad.
> Why? Because
> of http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Monad.html ! Look at all the cool stuff you can automagically do with your type just because it's an instance of Monad! I think that's the point. What can you do with arbitrary Monoids? Not much, as evidenced by http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Monoid.html

Data.Foldable has several functions that use an arbitrary monoid.

A new API I've been working on for manipulating cabal files uses a tree
of values of any monoid type.

Sets of installation paths is a monoid and is parametrised by another
monoid type (so we can have both sets of file paths and path templates).
A similar point applies for package indexes.

Most of the utility functions for handling command line arguments in
Cabal are parameterised by the monoid, because different command line
flags are different kinds of monoid. Some are list monoids, others are
first / last style monoids.


But it's not just the ability to write generic functions that is
relevant. By making a type an instance of Monoid instead of exporting
emptyFoo, joinFoo functions it makes the API clearer because it shows
that we are re-using an existing familiar concept rather than inventing
a new one. It also means the user already knows that joinFoo must be
associative and have unit emptyFoo without having to read the
documentation.

Duncan



More information about the Haskell-Cafe mailing list