ghc-proposals

GHC Proposals 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. ≡ List of proposals under discussion ≡ List of proposals waiting for shepherd recommendation ≡ List of proposals waiting for committee decision ≡ List of accepted proposals ≡ List of rejected proposals ≡ List of proposals needing revision ≡ List of proposals pending implementation ≡ List of implemented proposals ≡ List of all proposals 1   What is a proposal? A GHC Proposal is a document describing a proposed change to the compiler, the specification of the language it accepts, or the surrounding ecosystem. These include: A change to the syntax or semantics of the GHC/Haskell language (e.g. the various ShortImports proposals, do expressions without $) A major change to the user-visible behaviour of the compiler (e.g. the recent change in super-class solving, and -Wall behavior) The addition of major features to the compiler (e.g. -XTypeInType, GHCi commands, type-indexed Typeable representations) Changes that are not necessarily within the scope of the committee include: changes to declarations in base, which should be addressed to the Core Libraries Committee; changes to other core libraries, which should be addressed to the relevant library maintainers; changes to the GHC API, the plugin API, or compiler internals, which can be contributed following the usual GHC MR review workflow; bug fixes and other minor changes that do not warrant additional overheads. Should the GHC maintainers deem a change significant or controversial enough, they may, at their discretion, involve the GHC Steering Committee and ask the contributor to write a formal proposal. Proposals are evaluated against our principles, which cover both language design and language stability 2   The life cycle of a proposal This section outlines what stages a proposal may go through. 2.1   Table of stages In brief all stages of the Reviewing process are shown in the table. [*]Click the link to see a detailed description. [†]Click the link to see a list of proposals with this label at this stage / outcome. Stage [*] / Outcome GitHub label [†] Max duration Responsibility for next action Action New stage / Outcome Proposal creation ‒ Indefinite Author Pull request Community discussion Community discussion ‒ (No label) Indefinite Author Submit to committee Shepherd appointment Close request Withdrawn Withdrawn ‒ (Withdrawn) ‒ (PR closed) ‒ ‒ Shepherd appointment ‒ 1 week Secretary Assign shepherd Shepherd review Shepherd review Pending shepherd recommendation 2 weeks Shepherd Make recommendation Committee discussion Send back for revision Needs revision Committee discussion Pending committee review 4-5 weeks Shepherd Accept Accepted Reject Rejected Send back for revision Needs revision Needs revision Needs revision Indefinite Author Resubmit to committee Shepherd review Close request Withdrawn Rejected Rejected ‒ (PR closed) ‒ ‒ Accepted Accepted 2 weeks Author & Shepherd Do final corrections Implementation 1 week Shepherd / Secretary Merge Implementation Accepted (PR closed) Indefinite Unspecified Implement the proposal Implemented Implemented Implemented ‒ (PR closed) ‒ ‒ 2.2   Detailed list of stages The stage is identified by a GitHub label, which is identified in the following list. Stage: Proposal creation. (No label.) Responsibility for next action: author. The author drafts / writes / rewrites a proposal. When they are ready they submit the proposal to the wider Haskell community for discussion, as a pull request against this repository, which moves the proposal to the Community discussion stage. What is a proposal? How to start a new proposal How to amend an accepted proposal Language design principles Stage: Community discussion. (No label.) Responsibility for next action: author. The wider community discusses the proposal by commenting on the pull request, while the author refines the proposal. Discussion goals Guidelines for respectful communication How to comment on a proposal ≡ List of new proposals under discussion If the proposal is an amendment to an already accepted proposal, the committee secretary additionally labels that proposal with the Amendment label. Community discussion may continue indefinitely until the author takes one of the following actions: Action: Submit to committee. Once they are satisfied they have addressed everything raised in the discussion, the proposal author should explicitly comment on the proposal, asking the committee secretary to bring the proposal before the committee for review. This moves the proposal to the Shepherd appointment stage. The review process does NOT start automatically when the discussion ends. The Committee Secretary could remind in comments that it is the author's responsibility to move the proposal forward. How to bring a proposal before the committee Action: Close request. If as a result of the discussion the author no longer wishes to champion the proposal, they may withdraw the proposal at any time by closing the pull request. ≡ List of withdrawn proposals after community discussion If the author abandons their own proposal and the proposal sees no activity for a long time (more than a year), it might be closed by the committee secretary. At any time, the proposer could reopen a proposal. Outcome: Withdrawn. (No label with PR closed.) Withdrawn proposals are those that have been closed by the author themselves, or closed by the secretary because the proposal was dormant for a long time. This may be because the idea was unfinished, unimplementable, or inconsistent with the Haskell language. ≡ List of withdrawn proposals after community discussion ≡ List of withdrawn proposals after revision ≡ List of all withdrawn proposals Stage: Shephe