[Haskell-cafe] Stacking monads

[Brandon S. Allbery KF8NH]

On Oct 3, 2008, at 15:10 , Andrew Coppin wrote:
>> The reason for the separation of the two for many functions is so  
>> that types which are instances of only one of the two can still  
>> take advantage of the functionality.
>
> Well, that makes sense once you assume two seperate, unconnected  
> classes. I'm still fuzzy on that first point though.
>
>>> Foldable seems simplish, except that it refers to some odd  
>>> "monoid" class that looks suspiciously like "MonadPlus" but  
>>> isn't... wuh?
>> A Monoid is simply anything that has an identity element (mempty)  
>> and an associative binary operation (mappend). It is not necessary  
>> for a complete instance of Foldable.
>
> Again, it looks like MonadPlus == Monad + Monoid, except all the  
> method names are different. Why do we have this confusing duplication?


Because typeclasses aren't like OO classes.  Specifically:  while you  
can specify what looks like class inheritance (e.g. "this Monad is  
also a Monoid" you can't override inherited methods (because it's a  
Monad, you can't specify as part of the Monad instance the definition  
of a Monoid class function).  So if you want to define MonadPlus to  
look like a Monad and a Monoid, you have to pick one and *duplicate*  
the other (without using the same names, since they're already taken  
by the typeclass you *don't* choose).

Usually this isn't a problem, because experienced Haskell programmers  
don't try to use typeclasses for OO.  But there are the occasional  
mathematically-inspired relationships (Functor vs. Monad, MonadPlus  
vs. Monoid, Applicative vs. Monad, etc.) that can't be expressed  
"properly" as a result.

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery at kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery at ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH