[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