The libraries proposal process and containers
fox at ucw.cz
Sat Sep 25 00:59:03 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
> | 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
> * 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
More performance patches will come if/when we have SPECIALISABLE.
More information about the Libraries