Version 1 (modified by simonmar@…, 6 years ago) (diff)

The new Haskell' process

The Haskell Prime Process


The effort to define a new version of the Haskell language, Haskell-prime, was started in 2005. Since then we have made plenty of progress in exploring the design space, but relatively little progress towards a concrete revision of the language specification.

Around ICFP'08 there was some discussion amongst the committee as to the best way to proceed. The basic problem we identified is that the existing process was too monolithic. We had already decided to separate Haskell-prime into two stages, alpha and beta, so that we could defer the difficult topic of Functional Dependencies and Type Families until later, but even getting to the alpha stage was still a mammoth task and it was not clear that it would be done in a reasonable amount of time, if at all.

The committee discussed how we might make the process more incrememtal, so that it can be a sustainable, ongoing process that lasts beyond the current committee and beyond just one revision of the language. Many of us are familiar with these kind of ongoing incremental processes from open source software development, where it works well, so we plan to adopt aspects of these processes in the development of the Haskell language.


In concrete terms, here's the overview of the new process.

  • Modularise: proposals are developed independently, from idea to complete addendum (almost a patch to the Report). Each proposal is driven by a person or small group, not necessarily just committee members. The owner(s) of the proposal will be given access to modify the wiki. Ideally a proposal should be implemented in a compiler with a flag to turn it on and off, so people can experiment with it. In this sense, a proposal corresponds to a language "extension", although the proposal may not necessarily extend the language.
  • Regular release cycles: at regular intervals (currently 12 months), a new revision of the language standard will be released, by integrating some of the mature proposals into the previous revision.
  • There is a committee, collectively responsible for choosing which proposals to integrate. The committee has a chair and co-chair, who are responsible for editing and producing the new language definition. Every release cycle, the the chair, co-chair, and some of the committee are replaced.

Each cycle can tune the number of proposals it accepts so that it can be sure to complete on time. Proposals can continue along their development process independently of the language revision cycle, thus the only bottleneck in the process is the number of proposals that can be accepted in a given revision, but keeping this number low is a good thing: the lower the number of additions, the fewer interactions we have to worry about. Keeping the interactions to a manageable level drastically reduces the chances that errors will creep in.

The lifecycle of a proposal

Here's the lifecycle of a proposal, fleshing out a bit more what happens in the release cycle:

  • If after some discussion the proposal seems plausible, it is turned into a formal proposal and moved to the wiki (see ProposalTemplate). Each proposal has a name (e.g. RankNTypes), which should be used as a subject line prefix on the mailing list when discussing it.
  • The community discuss the proposal. Each proposal has an owner or owners who are responsible for refining the proposal. In order to be accepted, a proposal should precisely specify the language extension: its syntax, semantics (informally, as in the current Report), and interactions with other language features.
  • When broad consensus has been reached, the owner(s) document the changes and additions to the Report necessary to implement the proposal (an "addendum"). Having done this, the proposal can be marked "complete", and is a candidate for selection at the next language revision.
  • The committee discusses which proposals will go in the next release. The committee chair and co-chair are then responsible for aggregating the final addenda into a revision of the Report.


  • Throughout the year: discuss and refine proposals
  • Review period (August/September?): committee chooses which addenda to include
  • Haskell Symposium: Announcement of accepted proposals
  • Following the announcement, the report will be edited to incorporate the changes, and then published.

Major revisions

From time to time, when it is deemed appropriate, the committee may designate a release of the language a "major revision". It is expected that major revisions of the language will be supported for longer than the yearly releases, and provide the stable baseline needed for textbooks, for example.


We expect releases to be made late in the year, around September-October. Hence, each release will be named after the year following the year of release. For example, the language revision released in October 2009 will be named "Haskell 2010".

Compiler support

We expect that GHC will support a number of previous revisions to the language, with a flag such as -language-revision=2010. Individual extensions can be enabled and disabled separately as usual.

Other compilers can choose which revision(s) of the language are supported, though it is expected that most compilers will support at least the most recent major revision.