Assigning Shepherd: #738: Amend #669 to categorize more language extensions
Trevis Elser submitted proposal #738: Amend #669 to categorize more language extensions <https://github.com/ghc-proposals/ghc-proposals/pull/738> for the committee to review. I'd like to nominate *Adam Gundry* as the shepherd. Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst#9committee-process-for-responding-to-a-proposal> . If possible, please aim to make a recommendation by *7 August 2026*. Cheers Simon
Dear Committee, I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669: https://github.com/ghc-proposals/ghc-proposals/pull/738 I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept. When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0601-ex...). Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes. Cheers, Adam On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
I support this proposal. There is bound to be some debate around particular extensions, but Trevis has (I believe) been careful to put controversial ones into the "Remaining" (i.e. still uncategorised) set. Simon On Tue, 4 Aug 2026 at 21:29, Adam Gundry <adam@well-typed.com> wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 ( https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0601-ex...).
Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Seems reasonable to me, I just made one comment on the PR: I think OverloadedLists could be Deprecated rather than Legacy if we really think it doesn't have a future. Cheers Simon On Tue, 4 Aug 2026 at 21:29, Adam Gundry <adam@well-typed.com> wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 ( https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0601-ex...).
Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
+1 from me. Am Do., 6. Aug. 2026 um 15:00 Uhr schrieb Simon Marlow <marlowsd@gmail.com>:
Seems reasonable to me, I just made one comment on the PR: I think OverloadedLists could be Deprecated rather than Legacy if we really think it doesn't have a future.
Cheers Simon
On Tue, 4 Aug 2026 at 21:29, Adam Gundry <adam@well-typed.com> wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 ( https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0601-ex...).
Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Dear Committee, If you haven't already commented on #738, please take a look and check you agree with the categorization: https://github.com/ghc-proposals/ghc-proposals/pull/738 In particular I believe we are waiting for responses from: - Malte - Matthías - Rodrigo - Jakob - Erik Please try to respond by *15th September*. One particular point of discussion that arose is whether OverloadedLists should be Legacy or Deprecated (https://github.com/ghc-proposals/ghc-proposals/pull/738#discussion_r37289053...). Simon M argues we should more aggressively use Deprecated to warn people away from extensions which we believe are bad ideas; I argue that Legacy is a better compromise for cases that are in use and not actively in need of removal. Please do chime in with your views! Cheers, Adam On 04/08/2026 21:29, Adam Gundry wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 (https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0601-extension-lifecycle- framework.md#21-categories). Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
Dear Committee, I think Malte and Rodrigo have responded, but we are still lacking input from 3 other committee members. My opinion on Legacy vs. Deprecated for "bad idea to use this extension": Per definition, Legacy sounds good to me, even if I was initially surprised to see it used that way. I think the "problem" here is that I usually associate "Deprecated" in software with "bad idea to use this and it will be removed at some point", whereas "Legacy" I associate with "using this extension means you'll accumulate technical debt" and the "bad idea" part overwhelmingly suggests Deprecated. Maybe "Phase Out" is a better alias for Legacy for this purpose? Either way, this is splitting hairs; there are probably bigger fish to fry. Sebastian Am Fr., 4. Sept. 2026 um 16:56 Uhr schrieb Adam Gundry <adam@well-typed.com
:
Dear Committee,
If you haven't already commented on #738, please take a look and check you agree with the categorization:
https://github.com/ghc-proposals/ghc-proposals/pull/738
In particular I believe we are waiting for responses from:
- Malte - Matthías - Rodrigo - Jakob - Erik
Please try to respond by *15th September*.
One particular point of discussion that arose is whether OverloadedLists should be Legacy or Deprecated ( https://github.com/ghc-proposals/ghc-proposals/pull/738#discussion_r37289053...).
Simon M argues we should more aggressively use Deprecated to warn people away from extensions which we believe are bad ideas; I argue that Legacy is a better compromise for cases that are in use and not actively in need of removal. Please do chime in with your views!
Cheers,
Adam
On 04/08/2026 21:29, Adam Gundry wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 (https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0601-extension-lifecycle- framework.md#21-categories). Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
I think Malte and Rodrigo have responded, but we are still lacking input from 3 other committee members.
Which three? Is there a status list (e.g. the spreadsheet) showing the current status and voting? Simon On Mon, 5 Oct 2026 at 09:21, Sebastian Graf <sgraf1337@gmail.com> wrote:
Dear Committee,
I think Malte and Rodrigo have responded, but we are still lacking input from 3 other committee members.
My opinion on Legacy vs. Deprecated for "bad idea to use this extension": Per definition, Legacy sounds good to me, even if I was initially surprised to see it used that way. I think the "problem" here is that I usually associate "Deprecated" in software with "bad idea to use this and it will be removed at some point", whereas "Legacy" I associate with "using this extension means you'll accumulate technical debt" and the "bad idea" part overwhelmingly suggests Deprecated. Maybe "Phase Out" is a better alias for Legacy for this purpose? Either way, this is splitting hairs; there are probably bigger fish to fry.
Sebastian
Am Fr., 4. Sept. 2026 um 16:56 Uhr schrieb Adam Gundry < adam@well-typed.com>:
Dear Committee,
If you haven't already commented on #738, please take a look and check you agree with the categorization:
https://github.com/ghc-proposals/ghc-proposals/pull/738
In particular I believe we are waiting for responses from:
- Malte - Matthías - Rodrigo - Jakob - Erik
Please try to respond by *15th September*.
One particular point of discussion that arose is whether OverloadedLists should be Legacy or Deprecated ( https://github.com/ghc-proposals/ghc-proposals/pull/738#discussion_r37289053...).
Simon M argues we should more aggressively use Deprecated to warn people away from extensions which we believe are bad ideas; I argue that Legacy is a better compromise for cases that are in use and not actively in need of removal. Please do chime in with your views!
Cheers,
Adam
On 04/08/2026 21:29, Adam Gundry wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 (https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0601-extension-lifecycle- framework.md#21-categories). Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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 <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Sorry for the late response. I have never used OverloadedLists myself and have only encountered it once on other code bases. I therefore have no string opinion on Legacy vs Deprecated. I support this proposal. Erik Sebastian Graf wrote:
Dear Committee,
I think Malte and Rodrigo have responded, but we are still lacking input from 3 other committee members.
My opinion on Legacy vs. Deprecated for "bad idea to use this extension": Per definition, Legacy sounds good to me, even if I was initially surprised to see it used that way. I think the "problem" here is that I usually associate "Deprecated" in software with "bad idea to use this and it will be removed at some point", whereas "Legacy" I associate with "using this extension means you'll accumulate technical debt" and the "bad idea" part overwhelmingly suggests Deprecated. Maybe "Phase Out" is a better alias for Legacy for this purpose? Either way, this is splitting hairs; there are probably bigger fish to fry.
Sebastian
Am Fr., 4. Sept. 2026 um 16:56 Uhr schrieb Adam Gundry <adam@well-typed.com
:
Dear Committee,
If you haven't already commented on #738, please take a look and check you agree with the categorization:
https://github.com/ghc-proposals/ghc-proposals/pull/738
In particular I believe we are waiting for responses from:
- Malte - Matthías - Rodrigo - Jakob - Erik
Please try to respond by *15th September*.
One particular point of discussion that arose is whether OverloadedLists should be Legacy or Deprecated ( https://github.com/ghc-proposals/ghc-proposals/pull/738#discussion_r37289053...).
Simon M argues we should more aggressively use Deprecated to warn people away from extensions which we believe are bad ideas; I argue that Legacy is a better compromise for cases that are in use and not actively in need of removal. Please do chime in with your views!
Cheers,
Adam
On 04/08/2026 21:29, Adam Gundry wrote:
Dear Committee,
I encourage you to take a look at Trevis' proposal to categorise the stability of more language extensions, by amending the existing categorization in proposal #669:
https://github.com/ghc-proposals/ghc-proposals/pull/738
I think we should accept this in principle. However, this proposal is somewhat atypical as it consists of many small decisions about individual extensions. Thus I suggest it may be easiest to comment on specific lines of the MR and discuss any changes there. Once more people have opined on the categorization, we can confirm whether there is consensus to accept.
When reviewing, please bear in mind the definitions of the categories as set out in proposal #601 (https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0601-extension-lifecycle- framework.md#21-categories). Note in particular that use of Deprecated extensions should result in warnings, and that declaring an extension Stable implies that it is highly unlikely to be subject to breaking changes.
Cheers,
Adam
On 24/07/2026 11:02, Simon Marlow wrote:
Trevis Elser submitted proposal #738:
Amend #669 to categorize more language extensions <https://github.com/ ghc-proposals/ghc-proposals/pull/738>
for the committee to review.
I'd like to nominate *Adam Gundry* as the shepherd.
Please guide us to a conclusion as outlined in the committee processes <https://github.com/ghc-proposals/ghc-proposals/blob/master/ README.rst#9committee-process-for-responding-to-a-proposal>.
If possible, please aim to make a recommendation by *7 August 2026*.
Cheers Simon
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
participants (5)
-
Adam Gundry -
Erik de Castro Lopo -
Sebastian Graf -
Simon Marlow -
Simon Peyton Jones