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@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH