Proposal: Change to library proposal process

[Chris Dornan]

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 at haskell.org [mailto:libraries-bounces at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110107/a0af320b/attachment.htm>