[Haskell-cafe] Stacking monads

Andrew Coppin andrewcoppin at btinternet.com
Fri Oct 3 15:47:36 EDT 2008

David Menendez wrote:
> For some monads, there are implementations of <*> which are more
> efficient than the one provided by ap. Similarly, there are ways to
> implement fmap which are more efficient than using liftM.
> Of course, the *real* reason we don't define the instance given above
> is that there are instances of Applicative that aren't monads, and we
> want to avoid overlapping instances.

OK, now I understand. (Of course, if Applicative was already a 
superclass of Monad, presumably that last wouldn't still stand?)

>> Well, that makes sense once you assume two seperate, unconnected classes.
>> I'm still fuzzy on that first point though.
> It's historical.

Ah. So "brokenness in the name of backwards compatibility"?

(Is this why we have "alternate Prelude modules"?)

>> Again, it looks like MonadPlus == Monad + Monoid, except all the method
>> names are different. Why do we have this confusing duplication?
> There are at least three reasons why MonadPlus and Monoid are distinct.
> First, MonadPlus is older than Monoid, even though Monoid is more general.
> Second, MonadPlus and Monoid have different kinds, * -> * and *,
> respectively. Instances of MonadPlus are more restricted, because they
> have to work with any type parameter, whereas instances of Monoid can
> place constraints.
> Third, instances of MonadPlus must follow additional laws relating the
> behavior of mplus and mzero to return and (>>=).

OK, good.

Also, I notice that the documentation for Monoid mentions that numbers 
form one. But that's not actually correct. Numbers for *several*! And 
yet, a given number type can only have *one* Monoid instance. (Or 
indeed, only one instance for _any_ typeclass.) How do you get round that?

More information about the Haskell-Cafe mailing list