This repository contains specifications for proposed changes to the Glasgow Haskell Compiler. The purpose of the GHC proposal process and of the GHC Steering Committee, is to broaden the discussion of the evolution of GHC.
The author drafts a proposal.
The author submits the proposal to the wider Haskell community for discussion, as a pull request against this repository.
The wider community discusses the proposal in the commit section of the pull request, while the author refines the proposal. This phase lasts as long as necessary.
Discussion goals • How to comment on a proposal • ≡ List of proposals under discussion
Eventually the proposal author brings the proposal before the committee for review.
How to bring a proposal before the committee • Who is the committee?
One committee member steps up as a shephard, and generates consensus within the commitee within four or five weeks.
Committee process • Review criteria • ≡ List of proposals under review
Eventually, the committee rejects a proposal, or passes it back to the author for review, or accepts it.
If a proposal sees no activity for along time, they are marked as “dormant”.
Once a proposal is accepted, it still has to be implemented. The author may do that, or someone else. Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate the code-base too much.
Do not hesitate to contact us if you have questions.
A GHC Proposal is a document describing a proposed change to the compiler, the
GHC/Haskell language, or the libraries in the GHC.* module namespace. These
include,
- A syntactic change to GHC/Haskell (e.g. the various
ShortImportsproposals,doexpressions without$) - A major change to the user-visible behaviour of the compiler (e.g. the recent
change in super-class
solving, and
-Wallbehavior) - The addition of major features to the compiler (e.g.
-XTypeInType, GHCi commands, type-indexedTypeablerepresentations)
Each proposal document must follow the following outline. A template is provided in proposal template.
- Motivation: Give a strong reason for why the community needs this change. Describe the use case as clearly as possible and give at least one concrete example. Explain how the status quo is insufficient or not ideal.
- Proposed Change Specification: Specify the change in precise and comprehensive yet concise language. Your specification may include,
- grammar and semantics of any new syntactic constructs
- the types and semantics of any new library interfaces
- how the proposed change addresses the original problem (perhaps referring back to the example)
- Effect and Interactions. Detail how the proposed change addresses the original problem raised in the motivation. Detail how the proposed change interacts with existing language or compiler features. Think about what surprising or problematic interactions may occur.
- Costs and Drawbacks. What are the drawbacks and costs to the community should this change be implemented? For example, does this make Haskell harder to learn for novice users? Does it make Haskell code harder to read or reason about? Will the implementation be complex or invasive?
- Alternatives: List alternatives to your proposed change and discuss why they are insufficient.
- Unresolved questions: Explicitly list any remaining issues that remain in the conceptual design and specification. Be upfront and trust that the community will help. Please do not list implementation issues.
- Implementation Plan (Optional): If accepted who will implement the change? It's quite okay to say "unknown" if you don't feel willing or able to carry out the implementation yourself.
Note that proposals are written in ReStructuredText rather than Markdown for its expressiveness and ease of integration into other GHC infrastructure. See the GHC Users Guide for a brief introduction to ReStructuredText.
To start a proposal, create a pull request that adds your proposal as proposals/0000-proposal-name.rst. Use proposals/0000-template.rst as a template.
If you are unfamiliar with git and github, you can use the GitHub web interface to perform these steps:
- This link loads the proposal template.
- Change the filename and edit the proposal.
- Press “Commit new file”
The pull request summary should include a brief description of your proposal, along with a link to the rendered view of proposal document in your branch. For instance,
This is a proposal augmenting our existing `Typeable` mechanism with a variant, `Type.Reflection`, which provides a more strongly typed variant as originally described in [A Reflection on Types](http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-dynamic/index.htm) (Peyton Jones, _et al._ 2016). [Rendered](https://github.com/bgamari/ghc-proposals/blob/typeable/proposals/0000-type-indexed-typeable.rst)
Members of the Haskell community are warmly invited to offer feedback on proposals. Feedback ensures that a variety of perspectives are heard, that alternative designs are considered, and that all of the pros and cons of a design are uncovered. We particularly encourage the following types of feedback,
- Completeness: Is the proposal missing a case?
- Soundness: Is the specification sound or does it include mistakes?
- Alternatives: Are all reasonable alternatives listed and discussed. Are the pros and cons argued convincingly?
- Costs: Are the costs for implementation believable? How much would this hinder learning the language?
- Other questions: Ask critical questions that need to be resolved.
- Motivation: Is the motivation reasonable?
To comment on a proposal you need to be viewing the proposal's diff in "source diff" view. To switch to this view use the buttons on the top-right corner of the Files Changed tab.
Use the view selector buttons on the top right corner of the "Files Changed" tab to change between "source diff" and "rich diff" views.
Feedback on a open pull requests can be offered using both GitHub's in-line and pull request commenting features. Inline comments can be added by hovering over a line of the diff.
Hover over a line in the source diff view of a pull request and
click on the + to leave an inline comment
For the maintenance of general sanity, try to avoid leaving "me too" comments. If you would like to register your approval or disapproval of a particular comment or proposal, feel free to use GitHub's "Reactions" feature.
When the discussion has ebbed down and the author thinks the proposal is ready, he
- reviews the discussion thread and ensure that the proposal text accounts for all salient points.
- adds a comment to the a pull request, briefly summarizing the major points raised
during the discussion period and stating your belief that the proposal is
ready for review. In this comment, tag the committee secretary (currently
@nomeata).
The secretary, will then label the pull request with
Pending committee review and notify the committee. (If this does not happen
within a day or two, please ping the secretary or the committee.)
In order to keep better track of actively discussed proposals, proposals that
see no activity for an extended period of time (a month or two) might be marked
as “dormant”. At any time the proposor, or someone else can revive the
proposal by picking up the discussion (and possibly asking the secretary to remove the dormant tag).
You can see the list of dormant proposals.
The current members of the GHC steering committe, who you can reach by email at ghc-steering-committee@haskell.org, are:
| Christopher Allen | @bitemyapp | |
| Joachim Breitner | @nomeata | secretary |
| Manuel M T Chakravarty | @mchakravarty | |
| Iavor Diatchki | @yav | |
| Richard Eisenberg | @goldfirere | |
| Ben Gamari | @bgamari | |
| Roman Leshchinskiy | @rleshchinskiy | |
| Simon Marlow | @simonmar | co-chair |
| Simon Peyton-Jones | @simonpj | co-chair |
Members have terms of 3, 4, and 5 years.
Once the committee has been notified that a proposal is ready for decision, the committee is responsible for making the deadline known and notifying the wider community for comment.
The committee organically determines which member who will oversee discussion of the proposal. If organic doesn’t work, our chair(s) assign the proposal to a member. Membership on the committee means that we will volunteer to handle proposals as appropriate. The committee member running this discussion process is the Shepherd of the proposal.
The shepherd and the committee are not responsible for reading GitHub (or other) commentary. The proposal will be considered on its own. If the author wishes the committee to consider any commentary, that commentary should be incorporated into the proposal. Incorporation here means the information is summarized with attribution, not copied and pasted.
Once a decision is requested, the shepherd has four weeks (in holiday times or near the ICFP deadline, 5) to generate consensus. If consensus is elusive, then we vote, with the Simons retaining veto power. Naturally, if consensus occurs in less time, then a decision can be rendered early.
If we say no: the shepherd updates the proposal (not just the commentary) with the reasons for rejection. The pull request will be closed with label
Rejected.The proposer is welcome to revise and try again, but the document should retain this original rejection information.
In the case that the proposed change has already been implemented in GHC, it will be reverted.
If we say maybe: If during the Debate, the need for substantial changes does arise, we reject the proposal in its current state and it can go back to Development for revision.
If we say yes: A Trac ticket is created, referring back to the proposal and commentary. (The shepherd is responsible for making sure this happens.) At this point, the proposal process is technically complete. It is outside the purview of the committee to implement, oversee implementation, attract implementors, etc.
Below are some criteria that the committee and the supporting GHC community will generally use to evaluate a proposal. Note that this list is merely set of a guidelines; it is the committee's job to weigh these and any other relevant considerations appropriately.
Utility and user demand. What exactly is the problem that the feature solves? Is it an important problem, felt by many users, or is it very specialised? The whole point of a new feature is to be useful to people, so a good proposal will explain why this is so, and ideally offer evidence of some form.
Elegant and principled. Haskell is a beautiful and principled langauge. It is tempting to pile feature upon feature (and GHC Haskell has quite a bit of that), but we should constantly and consciously strive for simplicity and elegance.
This is not always easy. Sometimes an important problem has lots of solutions, none of which have that "aha" feeling of "this is the Right Way to solve this"; in that case we might delay rather than forge ahead regardless.
Fit with the language. If we just throw things into GHC willy-nilly, it will become a large ball of incoherent and inconsistent mud. We strive to add features that are consistent with the rest of the language.
Specification cost. Does the benefit of the feature justify the extra complexity in the language specification? Does the new feature interact awkwardly with existing features, or does it enhance them? How easy is it for users to understand the new feature?
Implementation cost. How hard is it to implement?
Maintainability. Writing code is cheap; maintaining it is expensive. GHC is a very large piece of software, with a lifetime stretching over decades. It is tempting to think that if you propose a feature and offer a patch that implements it, then the implementation cost to GHC is zero and the patch should be accepted.
But in fact every new feature imposes a tax on future implementors, (a) to keep it working, and (b) to understand and manage its interactions with other new features. In the common case the original implementor of a feature moves on to other things after a few years, and this maintenance burden falls on others.
Feel free to contact any of the members of the GHC Steering Committee with questions. Email
and IRC (#ghc on irc.freenode.net) are both good ways of accomplishing this.