This proposal is discussed at this pull request. After creating the pull request, edit this file again, update the number in the link, and delete this bold sentence.

This proposal sets up a process to introduce new language versions GHC20XX, extending Haskell2010 as defined by the Report with several extensions.

It has almost become a meme that any slightly-complex Haskell module starts with a dozen lines of {-# LANGUAGE #-} pragmas. This poses several problems:

• beginners often see features behind an extension as "advanced" or "obscure", even though some like LambdaCase or NamedFieldPuns are quite simple;
• some sorts of programming in Haskell -- mostly type-level oriented -- require enables lots of extensions (think of the usual combo MultiParamTypeClasses + FlexibleInstances + FlexibleContexts). Sometimes the fact that there are different extensions, instead of a single ExtendedTypeClasses is mostly historical.

For that reason, it's benefitial to pack those extensions which have "graduated" in terms of stability and usefulness into a single language version.

The second goal is to involve the community in the process. The previous reports, Haskell 98 and Haskell 2010, where designed by a Committee; but that was before the GHC Proposals process had taken shape.

We propose to introduce a process to develop new "language versions", dubbed GHC20XX, which extend Haskell2010 with some default extensions. This proposal does not set which extensions are included, rather seeks to provide a framework to reach a conclusion in a timely manner.

We define a set of six criteria. Not all criteria must be satisfied for an extension to be included, but there should be a stronger reason in that case.

1. The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning. We prefer to take this as a strict criteria, and grant exceptions on a case-by-case basis.
2. New failure modes that become possible with the extension are rare and/or easy to diagnose. These failure modes include new error messages, wrong inferred types, and runtime errors, for example. In other words, the developer experience should not get worse by adding this extension to the default mix.
3. The extensions complement the design of standard Haskell. This is the most subjective of the criteria. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement the current design.
4. The extension has been -- and can reasonably be predicted to remain -- stable.
5. The extension is not to gate-keep an advanced or potentially-unsafe feature. IncoherentInstances should not be enabled by default because of its potential unsafety.
6. The extension has widespread usage.

Upon acceptance of this proposal, a new repository ghc-proposals/ghc-language should be started.

Discussion about each extension should happen in a separate issue, in which the proponent should argument their reason for inclusion. We follow the same procedure as in GHC proposals: after enough time to gather feedback from the community, the GHC Steering Committee makes a final veredict about the inclusion. However, when a proposal is rejected, a new issue can be opened in the following cycle, if anybody feels that the extension is now ready for inclusion.

Every year the chosen set of extensions is packed as GHC20XX into the corresponding GHC version being released that year around spring. The deadline is strict, extensions in discussion need to wait for the next release cycle. The GHC Steering Committee shall appoint one of its members to make the required changes to both GHC and Cabal.

• Having a longer cycle than yearly, maybe every two/three years?

• Should we impose some time between a certain extension had been accepted by the GHC Proposals process and the ability to include it in a new language version?
• What is the relation (if any) between this new language versions and Haskell Prime?

(Optional) If accepted who will implement the change? Which other resources and prerequisites are required for implementation?

(Optional) This section provides an opportunty for any third parties to express their support for the proposal, and to say why they would like to see it adopted. It is not mandatory for have any endorsements at all, but the more substantial the proposal is, the more desirable it is to offer evidence that there is significant demand from the community. This section is one way to provide such evidence.