On Mon, Apr 21, 2014 at 11:33 AM, Mario Pastorelli
On 04/21/2014 04:22 PM, Casey McCann wrote:
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.
But it does somewhat deflate the notion that the fooM convention is consistently used, especially since replicateM and replicateM_ are probably more frequently used than many of the properly-named functions.
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?
Ah, so you're arguing that API consistency is sometimes outweighed by other concerns? I suppose I can't disagree with that. ;] Naming things is a matter of human language, and as a rule of thumb if everyone consistently breaks a linguistic "rule" in exactly the same way, it was the wrong rule. Figuring out what the actual rule being followed is and making it explicit is far more useful than trying to force a rule that runs counter to intuition. These functions have been reinvented many, many times under the names ifM &c., and between that and the strong association between the m prefix and MonadPlus/Monoid (as demonstrated by the fact you apparently didn't notice I compared "mreplicate" to "mconcat" above) I would argue that mif &c. are actually more misleading in this case, for the clear and simple reason that they're not the names most people would expect. Unless we plan to be absolutely and completely consistent, including renaming replicateM and mfix, we should use the widely established names in this case. - C.