Please review #669: Initial categorization of language extensions

Adam Gundry

29 Oct 2024 29 Oct '24

7:45 p.m.

Dear Committee, 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-categorizatio... I'd like to nominate Malte Ott as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Adam -- 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

Show replies by date

Malte Ott

23 Jun 23 Jun

1:11 p.m.

New subject: Please review #669: Initial categorization of language extensions

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-categorizatio...

(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

Arnaud Spiwack

1 Jul 1 Jul

8:57 a.m.

New subject: Please review #669: Initial categorization of language extensions

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@haskell.org> wrote:

...

Dear Committee,

...
Trevis Elser proposes a classification of (some) language extensions

On 2024-10-29 19:45, Adam Gundry wrote: 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-categorizatio...

(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@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.

Simon Peyton Jones

2 Jul 2 Jul

2:59 p.m.

New subject: Please review #669: Initial categorization of language extensions

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@haskell.org> wrote:

...

Dear Committee,

...
Trevis Elser proposes a classification of (some) language extensions

On 2024-10-29 19:45, Adam Gundry wrote: 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-categorizatio...

(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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Jakob Brünker

5 Jul 5 Jul

3:11 p.m.

New subject: Please review #669: Initial categorization of language extensions

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 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@haskell.org> wrote:

...
Dear Committee,

...
Trevis Elser proposes a classification of (some) language extensions

On 2024-10-29 19:45, Adam Gundry wrote: 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-categorizatio...

(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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Sebastian Graf

7 Jul 7 Jul

6:24 a.m.

New subject: Please review #669: Initial categorization of language extensions

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 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@haskell.org> wrote:

...
Dear Committee,

...
Trevis Elser proposes a classification of (some) language extensions

On 2024-10-29 19:45, Adam Gundry wrote: 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-categorizatio...

(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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Matthías Páll Gissurarson

1:51 p.m.

New subject: Please review #669: Initial categorization of language extensions

The list seems reasonable. I vote accept. On Mon, 7 Jul 2025 at 06:24, Sebastian Graf via ghc-steering-committee < ghc-steering-committee@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 :

...
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 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@haskell.org> wrote:

...
Dear Committee,

...
Trevis Elser proposes a classification of (some) language extensions

On 2024-10-29 19:45, Adam Gundry wrote: 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-categorizatio...

(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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- -- Matthías Páll Gissurarson http://mpg.is/

Adam Gundry

7 Aug 7 Aug

8:10 p.m.

New subject: Please review #669: Initial categorization of language extensions

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

Malte Ott

9:23 p.m.

New subject: 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

Age (days ago)

340

Last active (days ago)

List overview

Download

8 comments

7 participants

participants (7)

Adam Gundry
Arnaud Spiwack
Jakob Brünker
Malte Ott
Matthías Páll Gissurarson
Sebastian Graf
Simon Peyton Jones

Please review #669: Initial categorization of language extensions

tags

participants (7)