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

Adam Gundry adam at well-typed.com
Thu Aug 7 20:10:19 UTC 2025


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