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.htm... ! 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