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

[Arnaud Spiwack]

I will not vote on this one because I don't feel that there's much value
either way. I don't feel invested enough to juge of whether it's well
designed or not, but *I don't want to block this initiative*. I did make a
small comment in the proposal thread which hopefully will lead to
simplification of the classification, though.

On Mon, 23 Jun 2025 at 22:12, Malte Ott via ghc-steering-committee <
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/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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250701/563ae6ae/attachment.html>