Proposal: add ifM and whenM to Control.Monad

[Edward Kmett]

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 at 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 at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140421/9dd2139f/attachment.html>