darcs patch: Add justIf to Data.Maybe
Simon Marlow
marlowsd at gmail.com
Tue Aug 25 07:32:00 EDT 2009
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
More information about the Libraries
mailing list