Proposal: add ifM and whenM to Control.Monad

[Alois Cochard]

For same reason as Andreas:
+1 to ifM/whenM/unlessM


On 21 April 2014 11:30, Andreas Abel <andreas.abel at ifi.lmu.de> wrote:

> I still believe in the intelligence of the masses, in particular when it
> comes to the evolution of vocabulary.
>
> Hayoo gives me 14 hits on "ifM", and 0 on "mif".
>
> +1 to ifM/whenM/unlessM
> -1 to mif/mwhen/munless
>
> CustomPrelude.
> ifM     :: m Bool -> m a -> m a -> m a
> custom-prelude
>
> Control.Conditional.
> ifM     :: m bool -> m a -> m a -> m a
> cond
>
> Bamboo.Helper.
> ifM     :: m Bool -> m b -> m b -> m b
> bamboo
>
> Control.Monad.Tools.
> ifM     :: m Bool -> m a -> m a -> m a
> yjtools
>
> Agda.Utils.Monad.
> ifM     :: m Bool -> m a -> m a -> m a
> Agda
>
> Sindre.Util.
> ifM     :: m Bool -> m a -> m a -> m a
> sindre
>
> Language.KURE.Combinators.Monad.
> ifM     :: m Bool -> m a -> m a -> m a
> kure
>
> Test.WebDriver.Commands.Wait.
> ifM     :: m bool -> m a -> m a -> m a
> webdriver
>
> Language.Fixpoint.Misc.
> ifM     :: m Bool -> m a -> m a -> m a
> liquid-fixpoint
>
> Scion.Utils.
> ifM     :: m Bool -> m a -> m a -> m a
> scion
>
> Feldspar.Core.Frontend.ConditionM.
> ifM     :: Data Bool -> M a -> M a -> M a
> feldspar-language
>
> Control.Monad.Rosso1.
> ifM     :: m Bool -> m a -> m a -> m a
> rosso
>
> Control.Monad.Adaptive.MonadUtil.
> ifM     :: m Bool -> m a -> m a -> m a
> Adaptive-Blaisorblade
>
> Control.Monad.Adaptive.MonadUtil.
> ifM     :: m Bool -> m a -> m a -> m a
> Adaptive
>
>
> On 21.04.14 11: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 are like me, they probably were ignoring the
>> naming convention and used the most intuitive name. Once you know forM
>> then it's obvious that you append 'M' to functions that "are more
>> monadic". Probably mif, mwhen and munless are more compatible with the
>> API rules.
>>
>>
>>> In general, I'm not sure about ifM (as it does not line up with `bool`).
>>>
>>>
>> This is the second time that I read about `bool` but I can't find it.
>> Can somebody provide a link to it? mbool can be a solution, but not as
>> intuitive as mif.
>>
>> Mario
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
> --
> Andreas Abel  <><      Du bist der geliebte Mensch.
>
> Theoretical Computer Science, University of Munich
> Oettingenstr. 67, D-80538 Munich, GERMANY
>
> andreas.abel at ifi.lmu.de
> http://www2.tcs.ifi.lmu.de/~abel/
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
*Alois Cochard*
http://aloiscochard.blogspot.com
http://twitter.com/aloiscochard
http://github.com/aloiscochard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140422/83db8660/attachment.html>