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

On Tue, Dec 30, 2014 at 1:05 PM, Johan Tibell <johan.tibell@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.