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.

-Edward

On Sun, Dec 28, 2014 at 1:14 PM, Yitzchak Gale <gale@sefer.org> 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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries