[Haskell-cafe] Stacking monads
Brandon S. Allbery KF8NH
allbery at ece.cmu.edu
Fri Oct 3 16:01:30 EDT 2008
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
More information about the Haskell-Cafe
mailing list