[Haskell-cafe] About mplus

Henning Thielemann lemming at henning-thielemann.de
Wed Sep 5 02:16:44 EDT 2007


On Tue, 4 Sep 2007, David Benbennick wrote:

> On 9/4/07, ok <ok at cs.otago.ac.nz> 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


More information about the Haskell-Cafe mailing list