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] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED]
electrical and computer engineering, carnegie mellon university KF8NH
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
