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

[Jakob Brünker]

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> 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> 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
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250705/58e0190e/attachment.html>