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