
On 04/21/2014 04:22 PM, Casey McCann wrote:
On Mon, Apr 21, 2014 at 8:55 AM, Brandon Allbery
wrote: On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli
wrote: On 04/21/2014 10:41 AM, Simon Hengel wrote:
A quick heuristic grep over all Hackage packages results in quite a bit of packages containing the ifM/whenM/unlessM: But that kind of shows that the "expected" names for those functions are ifM/whenM/unlessM. I would ask the question:
Are there any other useful combinators that would be named ifM/whenM/unlessM under the current naming convention?
If no, then I'm not entirely convinced that we should decide against what seems to be common intuition here.
Breaking API consistency because a lot of people are already doing it doesn't feel right. If they
The API is there to serve its users, not really to dictate to them. If the common convention is counter to the API structure, perhaps it is the API that should change. Has anyone noticed yet that replicateM is already breaking the ostensibly established naming scheme, and should properly be named mreplicate?
Sadly, replicateM breaks the naming scheme in a different way than ifM. The first doesn't justify the existence of the latter. replicate :: Int -> a -> [a] replicateM :: Monad m => Int -> m a -> m [a] if :: Bool -> a -> a -> a ifM :: Monad m => m Bool -> m a -> m a -> m a Only the name 'mif' respects the rules with this type. The more generic version of 'ifM' is ifM :: Monad m => m Bool -> a -> a -> a and I don't think there is a name conversion for this kind of function in Control.Monad.
But perhaps we should in fact rename replicateM. Certainly "mreplicate" would fit in better with other monadic variants of list functions, like "mconcat"! Consistency is important, after all.
Also, mfix should probably be fixM, for what that's worth.
Don't you think that for compatibility reason this can be very problematic? How many people already used replicateM (and replicateM_) in their code? How many times?