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

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 > wrote:

I vote accept as well.

Am Sa., 5. Juli 2025 um 17:11 Uhr schrieb Jakob Brünker via ghc- steering-committee >:

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 mailto:ghc-steering-committee@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 > 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