ok wrote:
On 5 Sep 2007, at 6:16 pm, Henning Thielemann wrote:
I think it is very sensible to define the generalized function in
terms of the specific one, not vice versa.
The specific point at issue is that I would rather use ++ than
`mplus`. In every case where both are defined, they agree, so
it is rather frustrating to be blocked from using an operator
which would otherwise have been appropriate.
You can. Just write:
(++) = mplus
in your programs (or in a module called OK.Utils or OK.Prelude!) and you
can use ++. It's not (normally) a big problem to rename functions in
haskell.
I am a little puzzled that there seems to be no connection between
MonadPlus and Monoid. Monoid requires a unit and an associative
binary operator. So does MonadPlus. Unfortunately, they have different
names. If only we'd had (Monoid m, Monad m) => MonadPlus m...
The correct connection is:
instance (Monoid (m a), Monad m) => MonadPlus m where
mplus = mappend
mzero = mempty
Except, of course, we can't reasonably require that. Because for any one
Monad m, there will be many ways to make (m a) into a Monoid, and most
of them will not form properly behaved MonadPlusses.
The converse notion is safer:
instance MonadPlus m => Monoid (m a) where
mappend = mplus
mempty = mzero
And I think the main reason we don't have this version, is that we can't
cope well with multiple instances. Many data types admit more than one
natural Monoid, and we don't have the language features to support that
very cleanly.
For example, there is also the Monoid:
instance Monad m => Monoid (m ()) where
mappend = (>>)
mempty = return ()
and these two are not necessarily compatible. In fact, on [a] (or
rather, [()]), the former gives us addition and the latter gives us
multiplication, viewing [()] as isomorphic to Nat. These are two very
well known monoids on Nat.
Jules
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
