Re: Proposal: Add filterM or filterA to Data.Sequence

I’m not sure I understand. Do you mean that |filterM| shouldn’t exist for data structures for which |filterM . toList| is as fast? If this is the case, I wish that it was at least specified in the documentation that e.g. “this function doesn’t exist because the naive composition is guaranteed to be optimised away / the faster version is actually impossible to write / etc.”. I find myself wondering way too often whether some piece of code I’ve written is a potential candidate for optimisation, and knowing in advance that the naive version is the “recommended” approach lets me not waste my time on benchmarking code which was already benchmarked by others. On 12/30/2014 08:05 PM, Johan Tibell wrote:

We should check that `filterM . toList` isn't as fast. That was the case for bytestring and we rejected adding filterM there for that reason.

On Mon, Dec 29, 2014 at 6:13 AM, Edward Kmett mailto:ekmett@gmail.com> wrote:

+1 to just generalizing filterM in Data.Sequence

On Sun, Dec 28, 2014 at 12:22 AM, David Feuer mailto:david.feuer@gmail.com> wrote:

This can be given exactly the same implementation as the one for lists:

filterM :: (Applicative f) => (a -> f Bool) -> Seq a -> f (Seq a) filterM p = foldr go (pure empty) where go x r = f <0.3927809241601645gt; p x <*> r where f flg ys = if flg then x <| ys else ys

Bikeshed all you like over the name. _______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org mailto:Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

​