Proposal: Add filterM or filterA to Data.Sequence

Johan Tibell johan.tibell at
Tue Dec 30 19:27:37 UTC 2014

On Tue, Dec 30, 2014 at 1:21 PM, David Feuer <david.feuer at> wrote:

> On Tue, Dec 30, 2014 at 1:05 PM, Johan Tibell <johan.tibell at>
> wrote:
> > The obvious downside is the explosion of functions in the API, which is
> even
> > worse due to their already being lazy and strict versions of most
> > higher-order function (i.e. now we'd have to have 2*2 versions of every
> > function). This seems like a failure in composability and abstraction.
> Until
> > we've figured out a way to deal with this general issue that doesn't
> involve
> > duplicating tons of code and swelling the API, I've been pushing back on
> > changes like this.
> 1. I think it's better to duplicate code in a library than to make its
> users duplicate the code themselves.

I tend to disagree, especially if we're not talking about duplicating

    filterMSeq f = fmap fromList . filterM f . toList

but the whole implementation of Seq.filter (which would need to if you want
an optimal implementation of filterMSeq).

> 2. One option would be to make Data.Sequence.Private, exposing all the
> types and various internals as well as defining all the necessary
> instances, and then to add Data.Sequence.This, Data.Sequence.That,
> etc.

I don't want to expose the internals (we don't do that for other containers
types) because we wouldn't, in practice, be able to change the
implementation if we wanted to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list