darcs patch: Add justIf to Data.Maybe

[Simon Marlow]

On 22/08/2009 16:22, Jon Fairbairn wrote:
> Duncan Coutts<duncan.coutts at worc.ox.ac.uk>  writes:
>
>> On Sat, 2009-08-22 at 10:18 +0200, Joachim Breitner wrote:
>>> Hi,
>>>
>>> I propose the attached change
>>
>>> Fri Aug 21 19:17:12 CEST 2009  Joachim Breitner<mail at joachim-breitner.de>
>>>    * Add justIf to Data.Maybe
>
>> As Jón was suggesting we might want to generalise to MonadPlus rather
>> than putting it in Data.Maybe, it becomes rather similar to the existing
>> function 'guard':
>
> [...] some alpha conversion
>>
>> checkA :: MonadPlus m =>  Bool ->  a ->  m a
>> checkA True  x  = return x
>> checkA False _  = mzero
>>
>> Using a Bool for the condition is a tad more general than a predicate
>> like:
>>
>> checkB :: MonadPlus m =>  (a ->  Bool) ->  a ->  m a
>
> I'd say the generality comparison goes the other way:
>
>> In particular, the use case in Cabal does not fit the predicate pattern
>> because the condition is not a condition on the value being returned but
>> on something else in the environment.
>
> But you can write any
>
>     checkA e
> as
>     checkB $ const e

Right, but  checkB p x = checkA (p x) x.

Also, checkA p = (guard p >>) . return

> whereas a function like
>
>     all_spaces = checkB (all . isSpace)

I think that for consistency with if/then/else and guard we should use 
checkA.  It's not that hard to write

      all_spaces xs = checkA (all (isSpace xs)) xs

if that's really what you want.

I wouldn't call checkB more "general"; to me it's just a minor 
convenience issue, which is outweighed by consistency and simplicity.

> is hard to write using checkA (suppose you are doing something like “map
> (checkB predicate)”) since checkA doesn't look at the second argument.

the "applying check to a list" case is not hard either:

   zipWithM checkA (map p xs) xs

again, if that's what you want to do.

Cheers,
	Simon