Proposal: Add filterM or filterA to Data.Sequence

[Johan Tibell]

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

> On Tue, Dec 30, 2014 at 1:05 PM, Johan Tibell <johan.tibell at gmail.com>
> 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: <http://www.haskell.org/pipermail/libraries/attachments/20141230/876bab74/attachment.html>