Generalize filterM to Applicative

Edward Kmett ekmett at
Sun Dec 28 23:15:55 UTC 2014

The way we've been doing things so far is to just generalize the existing
signature and keep the existing name.

This avoids needless name proliferation and keeping needlessly
over-constrained versions of code lying around.

FWIW- I have no objection to a more general filterM.


On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <gale at> wrote:

> David Feuer wrote:
> > filterM          :: (Monad m) => (a -> m Bool) -> [a] -> m [a]
> > We could change this to
> > filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a]
> Following the usual conventions, that should be filterA.
> And I'm not sure where it should go. We could also
> generalize the list parameter to a Foldable and put
> it in Data.Foldable, but I don't think that would be
> very useful, since in the end it anyway returns a list.
> We could add a new "Filterable" class, but that's also
> probably not too useful for anything not list-like. For
> example, Data.Tree has two useful filters, filterGraft
> and filterPrune.
> So maybe it should go in Control.Applicative? Not very
> satisfying. Any ideas?
> As for the fate of the name filterM:
> Personally, I would want filterM to remain a convenient
> type-specialized version for monads. But recent madness
> would turn it into yet another unsightly overly polymorphic
> namespace wasting synonym for filterA.
> Thanks,
> Yitz
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list