On Mon, Apr 6, 2009 at 11:42 AM, David Menendez wrote:

Of course, this suggests that mfix should be fixM, so perhaps a better distinction is that mplus and mfix need to be defined per-monad, whereas filterM and replicateM are generic.

Don't you think that is an incidental distinction, not an essential one? It would be like naming our favorite operations mbind and joinM, just because of the way we happened to write the monad class. Luke

-- Dave Menendez <http://www.eyrie.org/~zednenem/ http://www.eyrie.org/%7Ezednenem/> _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 7 Apr 2009, at 07:37, David Menendez wrote:

On Mon, Apr 6, 2009 at 1:46 PM, Luke Palmer wrote:

...

On Mon, Apr 6, 2009 at 11:42 AM, David Menendez wrote:

...

Of course, this suggests that mfix should be fixM, so perhaps a better distinction is that mplus and mfix need to be defined per-monad, whereas filterM and replicateM are generic.

Don't you think that is an incidental distinction, not an essential one? It would be like naming our favorite operations mbind and joinM, just because of the way we happened to write the monad class.

Fair enough. I only added that comment when I noticed that my explanation for picking replicateM over mreplicate also applied to mfix.

Looking through Control.Monad, I see that all the *M functions require Monad, whereas the m* functions require MonadPlus (or MonadFix).

Actually, most of the *M functions only require Applicative – they're just written in a time when that wasn't in the libraries.

I wonder to what extent that pattern holds in other libraries?

I'm not sure how to generalise this pattern, but it's probably worth noting that fmap is fmap, not mapF. I can't see any pattern that it fits into, really I suspect it's a case of "what shall we name this" and not enough thought about consistant naming as the libraries evolved. Bob