On Tue, 4 Sep 2007, David Benbennick wrote:

On 9/4/07, ok <[EMAIL PROTECTED]> wrote:
I've been thinking about making a data type an instance of MonadPlus.
 From the Haddock documentation at haskell.org, I see that any such
instance should satisfy

        mzero `mplus` x = x
        x `mplus` mzero = x
        mzero >>= f     = mzero
        v >> mzero      = mzero

but is that all there is to it?  Are there no other requirements for
MonadPlus to make sense?

Also, mplus has to be associative.  I.e.
       (a `mplus` b) `mplus` c == a `mplus` (b `mplus` c)

I also wondered why, once MonadPlus was added to the language, the
definition of ++ wasn't changed to
        (++) = MonadPlus
(with the MonadPlus instance for [] defined directly).

You mean (++) = mplus.  I've wondered that too.  Similarly, one should
define map = fmap.

I think it is very sensible to define the generalized function in terms of the specific one, not vice versa.

 And a lot of standard list functions can be
generalized to MonadPlus, for example you can define

filter :: (MonadPlus m) => (a -> Bool) -> m a -> m a

Always using the most generalized form is not a good idea. If you know you are working on lists, 'map' and 'filter' tell the reader, that they are working on lists. The reader of a program doesn't need to start human type inference to deduce this. Also the type inference of the compiler will fail, if you write too general. Say, you are in GHCi, have your definition of 'filter' and you write

Prelude> filter Char.isUpper (return 'a')

To what monad this shall be specialised? Rely on type defaulting? Ok, you can use type signatures.


See also:
 http://www.haskell.org/haskellwiki/Slim_instance_declaration
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to