
On Fri, Dec 10, 2010 at 01:57:59PM +0100, Johan Tibell wrote:
On Fri, Dec 10, 2010 at 12:38 PM, Ross Paterson
wrote: The only thing the current setup prevents us from doing is changing interfaces without getting wider agreement -- I think that's a feature.
I'm not sure I agree. For example, IntMap didn't have strict versions insert and insertWith, making it practically impossible (due to crap performance) to efficiently keep an IntMap where the value was a counter of any kind (e.g. an Int). That took 4 months to fix as fixing it involved an API addition. FOUR MONTHS. If it had been my library it would have taken five minutes.
That would be this: http://hackage.haskell.org/trac/ghc/ticket/4257 The last 4 weeks of that period underline the problem with expecting Ian to apply all patches, especially when he was focussed on the stable branch. After the discussion period is up any committer could apply the patch, and we need a way of spreading that load. But most of the rest just shows the need for an active proposer.
Lets look at it another way, since the libraries maintained by libraries@ have a stricter process for API changes, they ought to have a better API than the ones that are maintained outside the process, right? At least in my opinion, the best libraries are all outside the libraries@ process: bytestring, binary, text, etc.
Don't you think the fact that these libraries are older, and their old interfaces have lots of users, might be a factor?