Proposal: Add filterM or filterA to Data.Sequence

[David Feuer]

On Tue, Dec 30, 2014 at 6:22 PM, Milan Straka <fox at ucw.cz> wrote:
> Hi all,
>
>> -----Original message-----
>> From: David Feuer <david.feuer at gmail.com>
>> 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.

David