Skip to content
Snippets Groups Projects

process

Last edited by igloo

The Haskell Prime Process

Background

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.

Overview

  • Proposals: each proposal describes a single change to the language. Proposals start life as a discussion on the mailing list, and end up as a complete description of the proposed changes to the language spec, at which point the proposal is a candidate for inclusion in the next revision. More details in the Proposals section below.

  • 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. Each revision is announced around October-November.

  • There is a committee, collectively responsible for choosing which proposals to integrate. The committee has a chair (and possibly 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. The decision period during which the committee discusses which proposals to incorporate is short, and is essentially just a yes/no for each complete proposal.

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.

Proposals

The following describes the lifecycle of a proposal.

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

  • A proposal starts on the haskell-prime mailing list, with discussion amongst the community. Anyone can start a discussion about a proposed change to the language: just post to the list.

  • Ideally the language change should be implemented already, so that experience gained with the implementation can inform the discussion.

  • If after some discussion the proposal seems plausible, someone should volunteer to be the proposal owner. A committee member will give the owner access to the wiki and ticket system. The owner should

    • Decide on a name for the proposal, if it doesn't already have one. Names are in CamelCase, e.g. RankNTypes.
      The name should be used as a subject line prefix for mailing list discussion.
    • create a ticket for the proposal
    • create a wiki page using ProposalTemplate

  • Discussion continues, with the wiki page being gradually refined into a precise description of the proposal, and including rationale (points both for and against) arising during the discussion

  • The aim is to add to the proposal a "Report Delta", which is a list of changes to the report necessary to implement the change. When the report delta is complete, the ticket can be moved into the "complete" state, and the proposal is a candidate for acceptance in the next revision.

  • The committee discusses which proposals will go in the next revision. Following the discussion, the tickets are updated to reflect which proposals were accepted. Wiki pages for proposals will be updated with a summary of the points raised during this discussion. Proposals that were not accepted may be refined further and reconsidered in the next cycle.

Timeline

  • Throughout the year: discuss and refine proposals
  • The committee will meet in February, May, August and November. They will review proposals completed before that month, and make a decision about which to accept
  • After the committee has met, the decisions will be announced on the mailing list
  • In January of the following year, the committee chair will produce a revision of the language standard by incorporating the accepted proposals
  • A new committee will then be formed

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.

Naming

We expect releases to be made early in the year, normally during January. Each release will be named after the year of the release. For example, the language revision released in January 2014 will be named "Haskell 2014".

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.