Proposal: add new function "check" to Control.Monad

[Edward Kmett]

While I like the generic version of filter, and have written one myself, I
am somewhat concerned about the fact that Control.Monad is probably the
module most often imported unqualified and without an explicit import list
due to the sheer number of combinators that it provides and filter is a very
commonly used function in the Prelude.
Adding the generic version of filter with the same name to such a module
will likely break a good deal of code.

Jon's suggestion of mfilter (filterM?) based on the ad hoc naming
conventions in Control.Monad sounds pretty safe though.

 -Edward Kmett

On Wed, Aug 26, 2009 at 3:44 PM, Sebastian Fischer <
sebf at informatik.uni-kiel.de> wrote:

>
> On Aug 26, 2009, at 7:52 PM, Jon Fairbairn wrote:
>
> When designing a library, one should choose
>> the primitives so that future definitions are simple, both in
>> the complexity of the terms needed to define them and in the
>> thought needed to define them, rather than the simplicity of
>> definition of the primitives themselves. The reason that I
>> suggested check is that it seems to me that it gives both of
>> those things in a way that guard doesn't
>>
>
> I see. Also the type of guard is indeed unusual. Historically, guard seems
> inspired by conditions in list comprehensions but I would appreciate a
> sensible refactoring.
>
> When designing MonadPlus combinators from scratch I would probably
> implement
>
>  filter :: MonadPlus m => (a -> Bool) -> m a -> m a
>
> as a generalisation of the list function with the same name. After Davids
> remarks I'm not sure whether I would need
>
>  check f = filter f . return
>
> I agree to you reasoning to prefer check over guard but go one step further
> and prefer filter over check.
>
> I would vote for adding a generalized filter to Control.Monad. Using the
> name of the Prelude function on lists is justified because it is a
> generalisation just like many functions in Data.Foldable which also reuse
> Prelude names.
>
> Cheers,
> Sebastian
>
> --
> Underestimating the novelty of the future is a time-honored tradition.
> (D.G.)
>
>
>
> _______________________________________________
>  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/20090911/e580c46d/attachment.html