Proposal: Change to library proposal process

[Malcolm Wallace]

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