Proposal: Change to library proposal process

[Sterling Clover]

On Jan 7, 2011, at 5:33 AM, Malcolm Wallace wrote:

> 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.
> 
...
>  * 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.

This is a very good, provocative proposal. For a long time, talk of major changes to core typeclasses, etc. was considered "Haskell Prime" territory, even if it was recognized that most initial Haskell Prime work would focus on the language and not libraries. Then the Haskell Prime committee moved models and announced that libraries would follow their own process entirely. But there wasn't any corresponding move to alter/change/disrupt the libraries process in light of this.

So I agree that a library "big bang" is a very good idea, and there's a fairly standard litany of issues that could be dealt with all at once. That said, base+core is still a large amount of code. I think that there should be some sense of scope so that things don't stretch on.

First, the focus should be on API-breaking changes, and not implementation details. The latter can and should be dealt with as well, but this can be dealt with much more incrementally, and to a certain degree after there's consensus on the big issues. So a timetable should recognize those different phases.

Second, I think there will have to be some organized specialization with regards to different components of base and different core packages. For the most part, we can't expect the everybody to provide the same attention and care to every module -- I imagine implementors  of various modules will get quite a bit of leeway, subject to code review.

There should be a period of comprehensive discussion and review following the major work -- not a community approval process, but more of the beta process that ghc and the haskell-platform go through in different ways. In fact, there may need to be more than one iteration of this, depending on how smoothly things go.

Finally, once the whole process has wound up, effort should be made to make the transition as easy as possible. This means comprehensive documentation, and perhaps tools for automated code transformation, which haskell-src-exts now makes it feasible to write.

Cheers,
Sterl