On Fri, May 24, 2013 at 2:15 PM, Andreas Abel <andreas.abel@ifi.lmu.de> wrote:

[...]
Pointed is pretty bad for this. Or, maybe, it's good: there's nothing to reason about, because there's nothing you can reason about. It just does _something_ unspecified. Hopefully something that is good for combining with some other type class.

I've reluctantly come around to the Apply/Bind classes (despite them having bad names), because they actually follow the way people typically build up structure in algebra. Rarely do you see people defining 'a monoid is a pointed set equipped with an associative binary operation that uses the point as an identity.' It's much more likely that you see, 'a monoid is a semigroup with an identity for the binary operation.' I suspect that's even how many people would like to see the hierarchy at this point: Semigroup m => Monoid m. And not Default m => Monoid m, because Default is just ad-hoc nonsense (even if it's sometimes useful).

To answer your original question, perhaps a somewhat better way of characterizing the problem is probably talking about 'monoids m over type a'. Perhaps something like:

    class Monoid m => MonoidOver a m | m -> a where
      embed :: a -> m

which expresses that m is expected to be generated (as a monoid) by a in some way. Then maybe you can say something about how it interacts with the Monoid operations, which seems preferable to me to, "the operation of this class does anything, except if the type is also a monoid, or if it's also a monad...."