On Tue, 2010-10-05 at 20:29 +0100, Malcolm Wallace wrote:
On 5 Oct 2010, at 19:18, Bryan O'Sullivan wrote:
Well, if that's the consensus, then we're at an impasse, because the libraries process is a trackless mire as has been fairly clearly demonstrated over the past few days, and I'm not going to change the names or types of the text functions. I've got better things to do than slog through such an ungratifying and demoralising morass.
But if someone else were to track down all the name inconsistencies, fix them, and submit a patch to you, would you accept it?
I've not followed the entire thread but perhaps it has not been discussed sufficiently clearly that it is not a question of accidental inconsistencies. There was (and imho correct) choice to make the primary mode of operation on Text be substring rather than element based. Thus the substring options get the primary names and predicate versions that operate on elements get secondary names. It's also not at all clear to me (as someone with both an interest in bytestring and text) that it makes sense for bytestring to change to be substring based. It's plausible but it seems to me to make more sense to keep bytestring's operations element (ie byte) based rather than substring based. If everyone else thinks that it's vital that the same name in text be element based then we do have a tricky question with naming. We do want the primary operations to be substring, not element, so we would have to come up with some naming convention that lets us have sensible names for the primary operations while still having (much less useful) element based ones.
I've also been thinking, how come new packages in the HP are held to higher standards than the existing ones? AFAICT, many of the current packages are in the Platform simply because a ghc hacker once decided to use them (and hence they became widely distributed, regardless of quality). (Yes, I'm looking at you, parsec and containers.) Sadly, I don't have any better suggestions for a submissions process.
We were aware of the problem of the grandfathered packages when we started. As you say there's not an obvious solution. We don't want to just say that things keep getting in without enough review. There is also the opportunity to improve things that are there already, e.g. see the current proposal to improve mtl. Also, hopefully the higher quality of the newer packages will embarrass us enough into improving the existing ones. As for a demoralising process, perhaps we can make better use of proposers (as distinct from maintainers). There is also the consensus protocol [1] described in the procedure. We should also ask the steering committee [2] to help keep things moving along. Duncan [1]: http://trac.haskell.org/haskell-platform/wiki/AddingPackages#Consensus [2]: http://trac.haskell.org/haskell-platform/wiki/Members#SteeringCommittee