[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