I agree with Malcolm's conclusion: a big overhaul by a committed group would be an excellent idea. One of the reasons that I was wary of change is because of the fragility of the current set-up, in both the libraries and the organisation. A group of responsible folks with the job of piloting us to Hackage Nirvana along the lines that Malcolm has outlined would tamp down the fear of change considerably. Yes, thanks to those who have persisted in showing us the problem - it's much appreciated! Chris From: libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] On Behalf Of Malcolm Wallace Sent: 07 January 2011 10:34 To: Simon Marlow Cc: Haskell Libraries Subject: Re: Proposal: Change to library proposal process On 6 Jan 2011, at 11:32, Simon Marlow wrote:
the process would be more appropriate if we were basically happy with the APIs we have. On the contrary, we have plenty of large- scale changes that need making in base and other places, and forcing all changes through the library process is making it hard to get these cleanups done.
I'm coming around to the view that this small-scale API change review isn't getting us where we want to go. To really improve APIs we should have a group of people looking at the whole, and making strategic decisions. Let's figure out where we're going and how to get there, rather than making a series of tiny incremental steps (slowly).
I think I agree with this. If there is general unhappiness with the basic set of APIs, then doing a big-bang redesign of everything from scratch (yes, even as far as the Prelude) is probably the right way to go. It will be a big discussion, with plenty of arguments, but at least "the libraries committee" might only need to do it once every ten years, rather than the "death by a thousand cuts" model we have now.
Let's really make FilePath an ADT, make binary Handles a different type, move more of base out into separate packages, remove the Show superclass of Num, overhaul the containers API, finish creating the Exception hierarchy, etc. etc. We've had a period of stability, maybe now it's time for change, and lots of it.
These are all good changes: we have known for a long time they are desirable, but making them would be disruptive. This discussion has persuaded me that we are never going to get them, unless we do them wholesale in a single strike.
- maintainers are empowered to make API changes. - no formal review process for API changes, although there is an expectation that non-trivial changes would still be discussed on the list beforehand.
Actually, I think those process ideas are in danger of being understood to belong to the "incremental" model, not the "wholesale" one. My suggestion would be: * appoint (self-select?) a group of people who will commit to actively seeing this wholesale redesign through to the end. * freeze the existing set of core packages, e.g. base, containers, binary, etc. * design from scratch a new-base package. * redesign the other core packages around the new-base. * make a big-bang release of all of the new core packages at once. * encourage other packages on hackage to abandon dependencies on the old base, and move to new-base plus fresh packages that depend on it. The design discussions should be public of course, but basically, the job is to critique old code and write new code in collaboration amongst a small group of talented library designers. As a target, do you think such a group could aim to complete a draft redesign in time for Haskell 2012? Regards, Malcolm _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1191 / Virus Database: 1435/3365 - Release Date: 01/07/11