Proposal: Add filterM or filterA to Data.Sequence

David Feuer david.feuer at
Tue Dec 30 23:52:42 UTC 2014

On Tue, Dec 30, 2014 at 6:22 PM, Milan Straka <fox at> wrote:
> Hi all,
>> -----Original message-----
>> From: David Feuer <david.feuer at>
>> Sent: 30 Dec 2014, 18:03
>> There won't be any such numbers in this case, because access to the
>> details of the sequence structure does not seem to help implement this
>> function.
> sorry for not making clear -- I was interested in difference between the
> mentioned
> | filterMSeq f = fmap fromList . filterM f . toList
> and your foldr-based implementation. I can imagine that one can use
> filterMSeq in place instead of filterM, so that is why I am interested
> between filterMSeq and the specialized implementation (which is just
> a plain foldr + <|).

Oh, I really don't know which is better (and that's true also for
unfoldr and unfoldl--is the current implementation better or worse
than using fromList?).

> Note that it is not obvious what type does filterM has (unlike e.g. zip),
> now that we have Applicative and also filterM is changing in base. From
> this point of view, it makes sense to use
>   fmap fromList . filterM f . toList
> because then we do not have inconsistent filterM-s.

I have no problem with having filterM in Data.Sequence be more general
than filterM in Control.Monad for old versions.

I think both unfold(r/l) and filterM actually make a potential point
in my favor—if there are multiple implementations that seem
reasonable, having whichever turns out to be fastest in the library
will save users time benchmarking them.


More information about the Libraries mailing list