The libraries proposal process and containers

[Milan Straka]

> |  All these things do not touch API. The performance patches have
> |  benchmark results on them.
> |  
> |  I pushed hastily as I wanted to sort out the INLINE => INLINABLE issue
> |  and I was working on the top of my repo with all these performance
> |  changes.
> 
> Let's not go overboard here.  OK, Milan didn't do the Right Thing, but:
> 
> * It's GREAT that he has taken the time to improve the containers library.
>    It's used by lots of people, so the benefits will be widely felt.  But it takes
>    painstaking work to find make solid performance improvements.  Thank
>    you Milan!  We need more people like you.
> 
> * Most if not all of the changes relate to performance and not API.
>    And the last patch (itself pushed over-hastily by Simon M) had some negative
>    impact on code size that we've been keen to see rectified in time for
>    the GHC release.  (There is still time; we are only at release candidate
>    stage.)
> 
> * The maintainer of 'containers' is libraries at haskell.org, so I don't think
>    it's true to say that Milan isn't the maintainer. As I understand the 
>    protocol for such packages, one makes a proposal, and if there 
>    is no dissent, one pushes it.
> 
> I am agnostic about how to proceed from here.  We could roll back all the patches (Milan's and the previous one that Simon M pushed).  Or we could move on from here.
> 
> So don't feel bad, Milan.  Incidentally, do you have any more performance improvement in the pipeline?

No, the performance patches are currently all in. There are some API
changes (like the folds) I am thinking about, but the performance is
currently done.

More performance patches will come if/when we have SPECIALISABLE.

Thanks,
Milan