I, for one, could get behind just taking ifM, whenM, unlessM for these operations, proper naming conventions aside. They've been independently reinvented in 60+ packages with these exact names. If we do this, over time we'll save another 60+ packages the trouble of doing the same thing. -Edward On Mon, Apr 21, 2014 at 11:38 AM, Mario Pastorelli < pastorelli.mario@gmail.com> wrote:
On 04/21/2014 02:55 PM, Brandon Allbery wrote:
On Mon, Apr 21, 2014 at 5:35 AM, Mario Pastorelli < pastorelli.mario@gmail.com> 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.
I agree with you but I'm not the developer of this API. Considering how important is Control.Monad for Haskell I think it's important to pick the right name for new functions.
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries