[ghc-steering-committee] Please review #669: Initial categorization of language extensions

Malte Ott malte.ott at maralorn.de
Thu Aug 7 21:23:12 UTC 2025


Ah, I wholeheartedly agree. Sorry, for the delay.

There were no polishing requirements that I know of, so I accepted the proposal.

Thanks everyone.

Best,
Malte

On 2025-08-07 21:10, Adam Gundry wrote:
> Hi Malte,
> 
> This proposal looks like it could be accepted, but I'm not sure if any final
> polishing is needed?
> 
> Let's please try not to let proposals linger in the committee review state
> for too long!
> 
> Thanks,
> 
> Adam
> 
> 
> 
> On 07/07/2025 14:51, Matthías Páll Gissurarson via ghc-steering-committee
> wrote:
> > The list seems reasonable. I vote accept.
> > 
> > On Mon, 7 Jul 2025 at 06:24, Sebastian Graf via ghc-steering-committee
> > <ghc-steering-committee at haskell.org <mailto:ghc-steering-
> > committee at haskell.org>> wrote:
> > 
> >     I vote accept as well.
> > 
> >     Am Sa., 5. Juli 2025 um 17:11 Uhr schrieb Jakob Brünker via ghc-
> >     steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-
> >     steering-committee at haskell.org>>:
> > 
> >         This all seems very reasonable to me. I vote to accept.
> > 
> >         Jakob
> > 
> >         On Wed, Jul 2, 2025 at 4:59 PM Simon Peyton Jones via ghc-
> >         steering-committee <ghc-steering-committee at haskell.org
> >         <mailto:ghc-steering-committee at haskell.org>> wrote:
> > 
> >             I'm in support of this proposal.
> > 
> >             There is some discussion around the corners but lets get it
> >             done!
> > 
> >             Simon
> > 
> >             On Mon, 23 Jun 2025 at 14:12, Malte Ott via ghc-steering-
> >             committee <ghc-steering-committee at haskell.org <mailto:ghc-
> >             steering-committee at haskell.org>> wrote:
> > 
> >                 Dear Committee,
> > 
> >                 On 2024-10-29 19:45, Adam Gundry wrote:
> >                  > Trevis Elser proposes a classification of (some)
> >                 language extensions based
> >                  > on previous work in proposal #601 establishing
> >                 categories:
> >                  >
> >                  > https://github.com/ghc-proposals/ghc-proposals/
> >                 pull/669 <https://github.com/ghc-proposals/ghc-
> >                 proposals/pull/669>
> >                  >
> >                  > https://github.com/telser/ghc-proposals/blob/initial-
> >                 extension-categorization/proposals/0000-extension-
> >                 categorization.md <https://github.com/telser/ghc-
> >                 proposals/blob/initial-extension-categorization/
> >                 proposals/0000-extension-categorization.md>
> > 
> >                 (Note that additionally to adding the new proposal the
> >                 PR also contains a small diff to the previous proposal
> >                 #601.)
> > 
> >                 This proposal rested for a while, but after some
> >                 revisions at Zurihac I am
> >                 recommending to accept this proposal. The proposal is
> >                 the logical next step after
> >                 the acceptance of #601. It’s not pretty to have a
> >                 categorization but not use it
> >                 and I think the classification is very helpful to guide
> >                 users and us.
> > 
> >                 In the proposal Trevis nominates
> > 
> >                 72 extensions as stable,
> >                 10 extensions as deprecated,
> >                   5 extensions as legacy,
> >                   8 extensions as experimental
> > 
> >                 and
> > 
> >                 42 remain unclassified.
> > 
> >                 This only affects documentation and our future
> >                 decisions. Only observable
> >                 change in GHC will be that deprecated extensions
> >                 consistently get a warning
> >                 via -Wdeprecated-flags.
> > 
> >                 The intention is to basically just describe the status
> >                 quo with the
> >                 classification and defer all contentious extensions to
> >                 be classified later.
> > 
> >                 My general tendency is that we should err in the
> >                 direction of marking
> >                 extensions stable because at least for widely used
> >                 extensions, even those where
> >                 we are not very happy with the design, marking them
> >                 experimental is like giving
> >                 us a free pass to break our stability principle. Also
> >                 marking an extension
> >                 stable is not the same as "recommended" as it is
> >                 perfectly fine for an extension
> >                 to be stable but not part of a GHCXXXX language edition.
> > 
> >                 Note that "For an extension to be classified as Stable
> >                 it must be considered
> >                 Stable when used in combination of all possible, non-
> >                 mutually exclusive,
> >                 extensions that are already Stable." I admit that I
> >                 cannot judge this with
> >                 certainty for all listed extensions. To be honest I
> >                 learned e.g. of the
> >                 existence of NoTraditionalRecordSyntax from reading the
> >                 list. While I have been
> >                 told that the categorization has been produced in close
> >                 collaboration with GHC
> >                 devs I ask everyone to keep this in mind when reviewing
> >                 the list.
> > 
> >                 Please review the overall proposal and the proposed
> >                 categories. You can give
> >                 your approval conditional on moving some extensions to
> >                 "unclassified". Others
> >                 and I have already done so, so from my point of view the
> >                 list is good as is.
> > 
> >                 Best,
> >                 Malte
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
> 
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> 


More information about the ghc-steering-committee mailing list