i've just played a bit with monoids, especially with Ross Paterson's nice version of "class (Monoid b)=>Monoid(a->b)" mapped to Arrows, and Implicit Parameters (i tried to simulate dynamic instances). for me, i came to the conclusion, that it is easier and nicer to generalise some functions, to be able to set the used monoid-functions via parameter. (not implicit parameter!) minimizing the overhead, i read this in the libraries: [docu] class Monoid a where The monoid class. A minimal complete definition must supply mempty and mappend, and these should satisfy the monoid laws. [/docu] is that really the only minimal complete definition, that is implemented? how about mconcat? [code] mempty = mconcat [] mappend a b = mconcat [a,b] [/code] the mconcat may be not optimised, if there are only the "minimal complete definition" mempty and mappend; so, it is good, that mconcat is one of the class-functions... but writing only the optimized mconcat is a "minimal complete definition", too. by the way: instead of Ross Paterson's "Data.Monoid"(Date: 2005-09-13 15:52:31 GMT), i would prefer another class: [code] import Prelude hiding (sequence) import qualified Control.Monad import Control.Arrow class Sequence m where sequence :: [m a] -> m [a] instance Monad m => Sequence m where sequence = Control.Monad.sequence instance (Arrow f) => Sequence (f a) where sequence [] = pure (const []) sequence [f] = f >>> pure (:[]) sequence (f:fr) = (f &&& sequence fr) >>> pure (uncurry (:)) --Ross Paterson's Monoid: rp_concat :: (Monoid b) => [a->b] -> a->b rp_concat = mconcat . sequence rp_concat' :: (Arrow f,Monoid b) => [f a b] -> f a b rp_concat' fs = sequence fs >>> pure mconcat [/code]