The libraries proposal process and containers
simonpj at microsoft.com
Fri Sep 24 16:20:44 EDT 2010
| 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
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
* 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?
More information about the Libraries