#765: Pun warnings, recommendation: accept
Hi all, Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace: https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0... These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle). They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal. I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it. I recommend we accept. Please indicate whether you wish to accept this proposal. Jakob
Jakob Brünker wrote:
I recommend we accept.
Proposal seems sensible to me. Accept! Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
I'm generally OK with this proposal -- small benefits, but small costs too. I left some comments here. <https://github.com/ghc-proposals/ghc-proposals/pull/765#issuecomment-4978364292> Only one is substantial. - Do we really want to include list and tuple puns in the scope of the flag. Using () and (a,b) and [a] as types is so ubiquitous that few programs will compile warning free if you switch on `-Wpun-occurrences`. - Indeed, do we want to have `-Wpun-occurrences` at all. I argue against in my comment. Simon On Tue, 14 Jul 2026 at 22:28, Jakob Brünker <jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0...
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
I vote to accept the proposal. It's just a warning and it seems like a useful future compat mechanism where users avoid punning for more ergonomic dependently-typed programs. I explicitly vote to include list and puns in the scope as the flag (as currently proposed). Otherwise, what is the point of the warnings? Users who want to prepare for dependent types can just use -XNoListTuplePuns, which they should be doing anyway. Cheers, Sebastian Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones < simon.peytonjones@gmail.com>:
I'm generally OK with this proposal -- small benefits, but small costs too.
I left some comments here. <https://github.com/ghc-proposals/ghc-proposals/pull/765#issuecomment-4978364292>
Only one is substantial.
- Do we really want to include list and tuple puns in the scope of the flag. Using () and (a,b) and [a] as types is so ubiquitous that few programs will compile warning free if you switch on `-Wpun-occurrences`. - Indeed, do we want to have `-Wpun-occurrences` at all. I argue against in my comment.
Simon
On Tue, 14 Jul 2026 at 22:28, Jakob Brünker <jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0...
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ 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
I vote to accept as well. This will be very helpful in the future once dependent types land. I agree with Simon though, getting a warning for `g :: [a]` or `h :: (a,b)` would be very surprising for me without any extensions enabled. /Matti Palli On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com> wrote:
I vote to accept the proposal.
It's just a warning and it seems like a useful future compat mechanism where users avoid punning for more ergonomic dependently-typed programs.
I explicitly vote to include list and puns in the scope as the flag (as currently proposed). Otherwise, what is the point of the warnings? Users who want to prepare for dependent types can just use -XNoListTuplePuns, which they should be doing anyway.
Cheers, Sebastian
Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones < simon.peytonjones@gmail.com>:
I'm generally OK with this proposal -- small benefits, but small costs too.
I left some comments here. <https://github.com/ghc-proposals/ghc-proposals/pull/765#issuecomment-4978364292>
Only one is substantial.
- Do we really want to include list and tuple puns in the scope of the flag. Using () and (a,b) and [a] as types is so ubiquitous that few programs will compile warning free if you switch on `-Wpun-occurrences`. - Indeed, do we want to have `-Wpun-occurrences` at all. I argue against in my comment.
Simon
On Tue, 14 Jul 2026 at 22:28, Jakob Brünker <jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0...
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub: 1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists. 2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/changes#r3641114009). But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal. Cheers, Adam On 20/07/2026 23:06, Matthías Páll Gissurarson wrote:
I vote to accept as well. This will be very helpful in the future once dependent types land.
I agree with Simon though, getting a warning for `g :: [a]` or `h :: (a,b)` would be very surprising for me without any extensions enabled.
/Matti Palli
On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> wrote:
I vote to accept the proposal.
It's just a warning and it seems like a useful future compat mechanism where users avoid punning for more ergonomic dependently- typed programs.
I explicitly vote to include list and puns in the scope as the flag (as currently proposed). Otherwise, what is the point of the warnings? Users who want to prepare for dependent types can just use -XNoListTuplePuns, which they should be doing anyway.
Cheers, Sebastian
Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>:
I'm generally OK with this proposal -- small benefits, but small costs too.
I left some comments here. <https://github.com/ghc-proposals/ ghc-proposals/pull/765#issuecomment-4978364292>
Only one is substantial.
* Do we really want to include list and tuple puns in the scope of the flag. Using () and (a,b) and [a] as types is so ubiquitous that few programs will compile warning free if you switch on `-Wpun-occurrences`. * Indeed, do we want to have `-Wpun-occurrences` at all. I argue against in my comment.
Simon
On Tue, 14 Jul 2026 at 22:28, Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun- warnings/proposals/0000-pun-warnings.rst <https:// github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ proposals/0000-pun-warnings.rst>
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378>), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `- XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering- committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: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
-- 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
All, it seems we're largely in agreement that the proposal should be accepted. However it doesn't look like the disagreement on what to do with list and tuple syntax has been fully resolved. As I see it, there are three conceivable options of what to do with `-Wpun-uses` when `-XListTuplePuns` is enabled: 1. Warn for term-level and type-level usages of [] (with fewer than two elements) and () syntax - This was the original position of the proposal 2. Warn for type-level usages but not term-level usages - This is the position the proposal takes now 3. Don't ever warn on [] or () syntax 4. Don't accept the proposal - included for completeness I think this is best resolved by a vote, so it would be great if you could rank these options by August 28. (My own vote is 2 > 1 > 3 > 4.) Jakob On Wed, Aug 5, 2026 at 8:04 PM Adam Gundry <adam@well-typed.com> wrote:
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub:
1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists.
2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/changes#r3641114009).
But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal.
Cheers,
Adam
On 20/07/2026 23:06, Matthías Páll Gissurarson wrote:
I vote to accept as well. This will be very helpful in the future once dependent types land.
I agree with Simon though, getting a warning for `g :: [a]` or `h :: (a,b)` would be very surprising for me without any extensions enabled.
/Matti Palli
On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> wrote:
I vote to accept the proposal.
It's just a warning and it seems like a useful future compat mechanism where users avoid punning for more ergonomic dependently- typed programs.
I explicitly vote to include list and puns in the scope as the flag (as currently proposed). Otherwise, what is the point of the warnings? Users who want to prepare for dependent types can just use -XNoListTuplePuns, which they should be doing anyway.
Cheers, Sebastian
Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>:
I'm generally OK with this proposal -- small benefits, but small costs too.
I left some comments here. <https://github.com/ghc-proposals/ ghc-proposals/pull/765#issuecomment-4978364292>
Only one is substantial.
* Do we really want to include list and tuple puns in the scope of the flag. Using () and (a,b) and [a] as types is so ubiquitous that few programs will compile warning free if you switch on `-Wpun-occurrences`. * Indeed, do we want to have `-Wpun-occurrences` at all. I argue against in my comment.
Simon
On Tue, 14 Jul 2026 at 22:28, Jakob Brünker <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun- warnings/proposals/0000-pun-warnings.rst <https:// github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ proposals/0000-pun-warnings.rst>
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378>), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `- XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering- committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org
To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: ghc-steering-committee-leave@haskell.org>
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: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
-- 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
My vote is 2 > 3 > 1 > 4. Option 1 means `-Wpun-uses -XListTuplePuns` is essentially useless, because it will warn on every term-level tuple or empty/singleton list in the program! There is nothing a user can do to indicate that they really mean a term-level use (unlike at the type level where List/Tuple type constructors are available). Thus the warning is unactionable, short of `-XNoListTuplePuns`, and moreover the warning issues for programs that will be perfectly fine under `-XNoListTuplePuns`. (My other point was about specification, which I'm grateful Jaro has responded to in some detail. I haven't had a chance to fully page in the latest version, but I'm happy to see this proceed in any case.) Cheers, Adam On 21/08/2026 07:55, Jakob Brünker wrote:
All,
it seems we're largely in agreement that the proposal should be accepted. However it doesn't look like the disagreement on what to do with list and tuple syntax has been fully resolved. As I see it, there are three conceivable options of what to do with `-Wpun-uses` when `- XListTuplePuns` is enabled:
1. Warn for term-level and type-level usages of [] (with fewer than two elements) and () syntax - This was the original position of the proposal 2. Warn for type-level usages but not term-level usages - This is the position the proposal takes now 3. Don't ever warn on [] or () syntax 4. Don't accept the proposal - included for completeness
I think this is best resolved by a vote, so it would be great if you could rank these options by August 28.
(My own vote is 2 > 1 > 3 > 4.)
Jakob
On Wed, Aug 5, 2026 at 8:04 PM Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub:
1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists.
2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/ changes#r3641114009 <https://github.com/ghc-proposals/ghc-proposals/ pull/765/changes#r3641114009>). But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal.
Cheers,
Adam
On 20/07/2026 23:06, Matthías Páll Gissurarson wrote: > I vote to accept as well. This will be very helpful in the future once > dependent types land. > > I agree with Simon though, getting a warning for `g :: [a]` or `h :: > (a,b)` would be very surprising for me without any extensions enabled. > > /Matti Palli > > On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> wrote: > > I vote to accept the proposal. > > It's just a warning and it seems like a useful future compat > mechanism where users avoid punning for more ergonomic dependently- > typed programs. > > I explicitly vote to include list and puns in the scope as the flag > (as currently proposed). Otherwise, what is the point of the > warnings? Users who want to prepare for dependent types can just use > -XNoListTuplePuns, which they should be doing anyway. > > Cheers, > Sebastian > > Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>>: > > I'm generally OK with this proposal -- small benefits, but small > costs too. > > I left some comments here. <https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > ghc-proposals/pull/765#issuecomment-4978364292> > > Only one is substantial. > > * Do we really want to include list and tuple puns in the > scope of the flag. Using () and (a,b) and [a] as types is > so ubiquitous that few programs will compile warning free if > you switch on `-Wpun-occurrences`. > * Indeed, do we want to have `-Wpun-occurrences` at all. I > argue against in my comment. > > Simon > > > > On Tue, 14 Jul 2026 at 22:28, Jakob Brünker > <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com> <mailto:jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>>> wrote: > > Hi all, > > Our own Jaro Reinders, based on a proposal originally > by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- > Wpun-bindings`, to warn users when the same name appears in > the term namespace and type namespace: > > https://github.com/ghc-proposals/ghc-proposals/blob/pun- <https://github.com/ghc-proposals/ghc-proposals/blob/pun-> > warnings/proposals/0000-pun-warnings.rst <https:// > github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ <http://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/> > proposals/0000-pun-warnings.rst> > > These warnings would not be enabled by default, but would > bring us a step forward on the path outlined by the accepted > proposal #378 (Support the design for dependent types, > https://github.com/ghc-proposals/ghc-proposals/pull/378 <https:// github.com/ghc-proposals/ghc-proposals/pull/378> > <https://github.com/ghc-proposals/ghc-proposals/ pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378>>), > by supporting writing code in a way that plays well with the > principles described in that proposal (i.e. the lexical > scoping principle and syntactic unification principle). > > They are also a good match for the recently introduced `- > XNoListTuplePuns`, which already lets users avoid puns for > some builtin types. Any users of `-XNoListTuplePuns` will > likely want something along the lines of this proposal. > > I left some comments on the github thread but I think they > are small enough that they don't have to prevent us from > voting on it. > > I recommend we accept. > > Please indicate whether you wish to accept this proposal. > > Jakob > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee- <mailto:ghc-steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: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
-- 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 vote the same. On 2026-08-21 08:55, Adam Gundry wrote:
My vote is 2 > 3 > 1 > 4.
Option 1 means `-Wpun-uses -XListTuplePuns` is essentially useless, because it will warn on every term-level tuple or empty/singleton list in the program! There is nothing a user can do to indicate that they really mean a term-level use (unlike at the type level where List/Tuple type constructors are available). Thus the warning is unactionable, short of `-XNoListTuplePuns`, and moreover the warning issues for programs that will be perfectly fine under `-XNoListTuplePuns`.
(My other point was about specification, which I'm grateful Jaro has responded to in some detail. I haven't had a chance to fully page in the latest version, but I'm happy to see this proceed in any case.)
Cheers,
Adam
On 21/08/2026 07:55, Jakob Brünker wrote:
All,
it seems we're largely in agreement that the proposal should be accepted. However it doesn't look like the disagreement on what to do with list and tuple syntax has been fully resolved. As I see it, there are three conceivable options of what to do with `-Wpun-uses` when `- XListTuplePuns` is enabled:
1. Warn for term-level and type-level usages of [] (with fewer than two elements) and () syntax - This was the original position of the proposal 2. Warn for type-level usages but not term-level usages - This is the position the proposal takes now 3. Don't ever warn on [] or () syntax 4. Don't accept the proposal - included for completeness
I think this is best resolved by a vote, so it would be great if you could rank these options by August 28.
(My own vote is 2 > 1 > 3 > 4.)
Jakob
On Wed, Aug 5, 2026 at 8:04 PM Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub:
1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists.
2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/ changes#r3641114009 <https://github.com/ghc-proposals/ghc-proposals/ pull/765/changes#r3641114009>). But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal.
Cheers,
Adam
On 20/07/2026 23:06, Matthías Páll Gissurarson wrote: > I vote to accept as well. This will be very helpful in the future once > dependent types land. > > I agree with Simon though, getting a warning for `g :: [a]` or `h :: > (a,b)` would be very surprising for me without any extensions enabled. > > /Matti Palli > > On Mon, Jul 20, 2026 at 08:50 Sebastian Graf <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> wrote: > > I vote to accept the proposal. > > It's just a warning and it seems like a useful future compat > mechanism where users avoid punning for more ergonomic dependently- > typed programs. > > I explicitly vote to include list and puns in the scope as the flag > (as currently proposed). Otherwise, what is the point of the > warnings? Users who want to prepare for dependent types can just use > -XNoListTuplePuns, which they should be doing anyway. > > Cheers, > Sebastian > > Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>>: > > I'm generally OK with this proposal -- small benefits, but small > costs too. > > I left some comments here. <https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > ghc-proposals/pull/765#issuecomment-4978364292> > > Only one is substantial. > > * Do we really want to include list and tuple puns in the > scope of the flag. Using () and (a,b) and [a] as types is > so ubiquitous that few programs will compile warning free if > you switch on `-Wpun-occurrences`. > * Indeed, do we want to have `-Wpun-occurrences` at all. I > argue against in my comment. > > Simon > > > > On Tue, 14 Jul 2026 at 22:28, Jakob Brünker > <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com> <mailto:jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>>> wrote: > > Hi all, > > Our own Jaro Reinders, based on a proposal originally > by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- > Wpun-bindings`, to warn users when the same name appears in > the term namespace and type namespace: > > https://github.com/ghc-proposals/ghc-proposals/blob/pun- <https://github.com/ghc-proposals/ghc-proposals/blob/pun-> > warnings/proposals/0000-pun-warnings.rst <https:// > github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ <http://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/> > proposals/0000-pun-warnings.rst> > > These warnings would not be enabled by default, but would > bring us a step forward on the path outlined by the accepted > proposal #378 (Support the design for dependent types, > https://github.com/ghc-proposals/ghc-proposals/pull/378 <https:// github.com/ghc-proposals/ghc-proposals/pull/378> > <https://github.com/ghc-proposals/ghc-proposals/ pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378>>), > by supporting writing code in a way that plays well with the > principles described in that proposal (i.e. the lexical > scoping principle and syntactic unification principle). > > They are also a good match for the recently introduced `- > XNoListTuplePuns`, which already lets users avoid puns for > some builtin types. Any users of `-XNoListTuplePuns` will > likely want something along the lines of this proposal. > > I left some comments on the github thread but I think they > are small enough that they don't have to prevent us from > voting on it. > > I recommend we accept. > > Please indicate whether you wish to accept this proposal. > > Jakob > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee- <mailto:ghc-steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:ghc-steering-committee- leave@haskell.org>> > > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org>
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: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
-- 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
My vote is 2 > 3 > 1 > 4. Malte Ott <malte.ott@maralorn.de> schrieb am Fr., 21. Aug. 2026, 12:57:
I vote the same.
On 2026-08-21 08:55, Adam Gundry wrote:
My vote is 2 > 3 > 1 > 4.
Option 1 means `-Wpun-uses -XListTuplePuns` is essentially useless, because it will warn on every term-level tuple or empty/singleton list in the program! There is nothing a user can do to indicate that they really mean a term-level use (unlike at the type level where List/Tuple type constructors are available). Thus the warning is unactionable, short of `-XNoListTuplePuns`, and moreover the warning issues for programs that will be perfectly fine under `-XNoListTuplePuns`.
(My other point was about specification, which I'm grateful Jaro has responded to in some detail. I haven't had a chance to fully page in the latest version, but I'm happy to see this proceed in any case.)
Cheers,
Adam
On 21/08/2026 07:55, Jakob Brünker wrote:
All,
it seems we're largely in agreement that the proposal should be accepted. However it doesn't look like the disagreement on what to do with list and tuple syntax has been fully resolved. As I see it, there are three conceivable options of what to do with `-Wpun-uses` when `- XListTuplePuns` is enabled:
1. Warn for term-level and type-level usages of [] (with fewer than two elements) and () syntax - This was the original position of the proposal 2. Warn for type-level usages but not term-level usages - This is the position the proposal takes now 3. Don't ever warn on [] or () syntax 4. Don't accept the proposal - included for completeness
I think this is best resolved by a vote, so it would be great if you could rank these options by August 28.
(My own vote is 2 > 1 > 3 > 4.)
Jakob
On Wed, Aug 5, 2026 at 8:04 PM Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub:
1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists.
2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/ changes#r3641114009 < https://github.com/ghc-proposals/ghc-proposals/ pull/765/changes#r3641114009>). But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal.
Cheers,
Adam
On 20/07/2026 23:06, Matthías Páll Gissurarson wrote: > I vote to accept as well. This will be very helpful in the future once > dependent types land. > > I agree with Simon though, getting a warning for `g :: [a]` or `h :: > (a,b)` would be very surprising for me without any extensions enabled. > > /Matti Palli > > On Mon, Jul 20, 2026 at 08:50 Sebastian Graf < sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> wrote: > > I vote to accept the proposal. > > It's just a warning and it seems like a useful future compat > mechanism where users avoid punning for more ergonomic dependently- > typed programs. > > I explicitly vote to include list and puns in the scope as the flag > (as currently proposed). Otherwise, what is the point of the > warnings? Users who want to prepare for dependent types can just use > -XNoListTuplePuns, which they should be doing anyway. > > Cheers, > Sebastian > > Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>>: > > I'm generally OK with this proposal -- small benefits, but small > costs too. > > I left some comments here. <https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > ghc-proposals/pull/765#issuecomment-4978364292> > > Only one is substantial. > > * Do we really want to include list and tuple puns in the > scope of the flag. Using () and (a,b) and [a] as types is > so ubiquitous that few programs will compile warning free if > you switch on `-Wpun-occurrences`. > * Indeed, do we want to have `-Wpun-occurrences` at all. I > argue against in my comment. > > Simon > > > > On Tue, 14 Jul 2026 at 22:28, Jakob Brünker > <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com> <mailto:jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>>> wrote: > > Hi all, > > Our own Jaro Reinders, based on a proposal originally > by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- > Wpun-bindings`, to warn users when the same name appears in > the term namespace and type namespace: > > https://github.com/ghc-proposals/ghc-proposals/blob/pun- <https://github.com/ghc-proposals/ghc-proposals/blob/pun-> > warnings/proposals/0000-pun-warnings.rst <https:// > github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ <http://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/> > proposals/0000-pun-warnings.rst> > > These warnings would not be enabled by default, but would > bring us a step forward on the path outlined by the accepted > proposal #378 (Support the design for dependent types, > https://github.com/ghc-proposals/ghc-proposals/pull/378 <https:// github.com/ghc-proposals/ghc-proposals/pull/378> > <https://github.com/ghc-proposals/ghc-proposals/ pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378 ), > by supporting writing code in a way that plays well with the > principles described in that proposal (i.e. the lexical > scoping principle and syntactic unification principle). > > They are also a good match for the recently introduced `- > XNoListTuplePuns`, which already lets users avoid puns for > some builtin types. Any users of `-XNoListTuplePuns` will > likely want something along the lines of this proposal. > > I left some comments on the github thread but I think they > are small enough that they don't have to prevent us from > voting on it. > > I recommend we accept. > > Please indicate whether you wish to accept this proposal. > > Jakob > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto: ghc- steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee- <mailto:ghc-steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto: ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto: ghc-steering-committee- leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto: ghc- steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto: ghc-steering-committee- leave@haskell.org>> > > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:ghc-steering-committee-leave@haskell.org
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto: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
-- 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
Hi all, I'm assuming Jaro is abstaining because this is his proposal - among the remaining 9 members, we have 6 votes to accept, 2 OKs, and no votes to reject. Among the options for how to treat List and Tuple syntax, everyone who voted on that favored the version the proposal currently suggests. Therefore I will mark the proposal as accepted in its current form. Thank you for your votes. Jakob On Mon, Aug 24, 2026 at 7:41 AM Sebastian Graf <sgraf1337@gmail.com> wrote:
My vote is 2 > 3 > 1 > 4.
Malte Ott <malte.ott@maralorn.de> schrieb am Fr., 21. Aug. 2026, 12:57:
I vote the same.
On 2026-08-21 08:55, Adam Gundry wrote:
My vote is 2 > 3 > 1 > 4.
Option 1 means `-Wpun-uses -XListTuplePuns` is essentially useless, because it will warn on every term-level tuple or empty/singleton list in the program! There is nothing a user can do to indicate that they really mean a term-level use (unlike at the type level where List/Tuple type constructors are available). Thus the warning is unactionable, short of `-XNoListTuplePuns`, and moreover the warning issues for programs that will be perfectly fine under `-XNoListTuplePuns`.
(My other point was about specification, which I'm grateful Jaro has responded to in some detail. I haven't had a chance to fully page in the latest version, but I'm happy to see this proceed in any case.)
Cheers,
Adam
On 21/08/2026 07:55, Jakob Brünker wrote:
All,
it seems we're largely in agreement that the proposal should be accepted. However it doesn't look like the disagreement on what to do with list and tuple syntax has been fully resolved. As I see it, there are three conceivable options of what to do with `-Wpun-uses` when `- XListTuplePuns` is enabled:
1. Warn for term-level and type-level usages of [] (with fewer than two elements) and () syntax - This was the original position of the proposal 2. Warn for type-level usages but not term-level usages - This is the position the proposal takes now 3. Don't ever warn on [] or () syntax 4. Don't accept the proposal - included for completeness
I think this is best resolved by a vote, so it would be great if you could rank these options by August 28.
(My own vote is 2 > 1 > 3 > 4.)
Jakob
On Wed, Aug 5, 2026 at 8:04 PM Adam Gundry <adam@well-typed.com <mailto:adam@well-typed.com>> wrote:
I'm in favour of accepting this proposal, with a couple of caveats that I've raised on GitHub:
1. I think `-Wpun-uses` should warn on occurrences of list/tuple *types* but not *terms*. That makes it consistent with migrating to `NoListTuplePuns`. Warnings should be actionable, and in this case the action is to replace type-level occurrences of `[a]` with `List a`; there is no action to take for term-level lists.
2. The specification does not currently seem very precise to me, and I would ideally like to sharpen it up if we can come up with something (see discussion at https://github.com/ghc-proposals/ghc-proposals/pull/765/ changes#r3641114009 < https://github.com/ghc-proposals/ghc-proposals/ pull/765/changes#r3641114009>). But I see this may be difficult, and I don't see this as a fundamental blocker to the proposal.
Cheers,
Adam
On 20/07/2026 23:06, Matthías Páll Gissurarson wrote: > I vote to accept as well. This will be very helpful in the future once > dependent types land. > > I agree with Simon though, getting a warning for `g :: [a]` or `h :: > (a,b)` would be very surprising for me without any extensions enabled. > > /Matti Palli > > On Mon, Jul 20, 2026 at 08:50 Sebastian Graf < sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> wrote: > > I vote to accept the proposal. > > It's just a warning and it seems like a useful future compat > mechanism where users avoid punning for more ergonomic dependently- > typed programs. > > I explicitly vote to include list and puns in the scope as the flag > (as currently proposed). Otherwise, what is the point of the > warnings? Users who want to prepare for dependent types can just use > -XNoListTuplePuns, which they should be doing anyway. > > Cheers, > Sebastian > > Am Mi., 15. Juli 2026 um 10:25 Uhr schrieb Simon Peyton Jones > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com>>>: > > I'm generally OK with this proposal -- small benefits, but small > costs too. > > I left some comments here. <https://github.com/ghc- proposals/ <https://github.com/ghc-proposals/> > ghc-proposals/pull/765#issuecomment-4978364292> > > Only one is substantial. > > * Do we really want to include list and tuple puns in the > scope of the flag. Using () and (a,b) and [a] as types is > so ubiquitous that few programs will compile warning free if > you switch on `-Wpun-occurrences`. > * Indeed, do we want to have `-Wpun-occurrences` at all. I > argue against in my comment. > > Simon > > > > On Tue, 14 Jul 2026 at 22:28, Jakob Brünker > <jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com> <mailto: jakob.bruenker@gmail.com <mailto:jakob.bruenker@gmail.com>>> wrote: > > Hi all, > > Our own Jaro Reinders, based on a proposal originally > by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `- > Wpun-bindings`, to warn users when the same name appears in > the term namespace and type namespace: > > https://github.com/ghc-proposals/ghc-proposals/blob/pun- <https://github.com/ghc-proposals/ghc-proposals/blob/pun-> > warnings/proposals/0000-pun-warnings.rst <https:// > github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ <http://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/
> proposals/0000-pun-warnings.rst> > > These warnings would not be enabled by default,
but would
> bring us a step forward on the path outlined by the accepted > proposal #378 (Support the design for dependent
types,
<https://
github.com/ghc-proposals/ghc-proposals/pull/378> > <https://github.com/ghc-proposals/ghc-proposals/ pull/378 <https://github.com/ghc-proposals/ghc-proposals/pull/378 ), > by supporting writing code in a way that plays well with the > principles described in that proposal (i.e. the
lexical
> scoping principle and syntactic unification
principle).
> > They are also a good match for the recently
introduced `-
> XNoListTuplePuns`, which already lets users avoid puns for > some builtin types. Any users of
`-XNoListTuplePuns` will
> likely want something along the lines of this
proposal.
> > I left some comments on the github thread but I
think
they > are small enough that they don't have to prevent
us from
> voting on it. > > I recommend we accept. > > Please indicate whether you wish to accept this
proposal.
> > Jakob > > _______________________________________________ > ghc-steering-committee mailing list --
ghc-steering-
> committee@haskell.org <mailto:committee@haskell.org> <mailto:
ghc-
steering- <mailto:ghc-steering-> > committee@haskell.org <mailto:committee@haskell.org>> > To unsubscribe send an email to
ghc-steering-committee-
> leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee- <mailto:ghc-steering-committee-> > leave@haskell.org <mailto:leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:
ghc-
steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:
ghc-steering-committee-
leave@haskell.org>> > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- > committee@haskell.org <mailto:committee@haskell.org> <mailto:
ghc-
steering-committee@haskell.org <mailto:ghc-steering- committee@haskell.org>> > To unsubscribe send an email to ghc-steering-committee- > leave@haskell.org <mailto:leave@haskell.org> <mailto:ghc- steering-committee-leave@haskell.org <mailto:
ghc-steering-committee-
leave@haskell.org>> > > > _______________________________________________ > ghc-steering-committee mailing list -- ghc-steering- committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:
ghc-steering-committee-leave@haskell.org>
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ <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 <mailto:ghc-steering-committee@haskell.org> To unsubscribe send an email to ghc-steering-committee- leave@haskell.org <mailto:
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
-- 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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
On the one hand this is just a warning and not enabled by default, so its impact is small. On the other hand, I worry about the direction of travel here. Is the long term plan that we will stop using puns? So no more [a] and (a,b) types? Or maybe that's only if you're writing Dependent Haskell - but then I worry that we're heading for a fork in the language, which is something we specifically try to avoid. Cheers Simon On Tue, 14 Jul 2026 at 18:58, Jakob Brünker <jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0...
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
I feel like there are three options here: a) risk the fork b) drop the lexical scoping principle and use type directed resolution like Agda does c) give up on syntactic unification (and thus a major part of DH.) I don’t think this would be a terrible fork. And it is just a warning. There are actually a lot of warnings and rules that I enforce in my codebases which other projects don’t adhere to. When codes from differents sides of the fork meet in one module there is always an escape hatch. Best Malte On 2026-07-22 11:03, Simon Marlow wrote:
On the one hand this is just a warning and not enabled by default, so its impact is small.
On the other hand, I worry about the direction of travel here. Is the long term plan that we will stop using puns? So no more [a] and (a,b) types? Or maybe that's only if you're writing Dependent Haskell - but then I worry that we're heading for a fork in the language, which is something we specifically try to avoid.
Cheers Simon
On Tue, 14 Jul 2026 at 18:58, Jakob Brünker <[1]jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
[2]https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/pro posals/0000-pun-warnings.rst
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, [3]https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- [4]ghc-steering-committee@haskell.org To unsubscribe send an email to [5]ghc-steering-committee-leave@haskell.org
References
1. mailto:jakob.bruenker@gmail.com 2. https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0... 3. https://github.com/ghc-proposals/ghc-proposals/pull/378 4. mailto:ghc-steering-committee@haskell.org 5. mailto: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
On Wed, 22 Jul 2026 at 11:26, Malte Ott <malte.ott@maralorn.de> wrote:
I feel like there are three options here:
a) risk the fork b) drop the lexical scoping principle and use type directed resolution like Agda does c) give up on syntactic unification (and thus a major part of DH.)
I don’t think this would be a terrible fork. And it is just a warning. There are actually a lot of warnings and rules that I enforce in my codebases which other projects don’t adhere to. When codes from differents sides of the fork meet in one module there is always an escape hatch.
Stylistic forks are fine, indeed I'm sure we all have our own set of favourite warnings. That's why some warnings are not in -Wall. If this is just a stylistic fork then OK - I'm not familiar with all the subtleties here, happy to be informed. Cheers Simon
Best Malte
On 2026-07-22 11:03, Simon Marlow wrote:
On the one hand this is just a warning and not enabled by default, so its impact is small.
On the other hand, I worry about the direction of travel here. Is the long term plan that we will stop using puns? So no more [a] and (a,b) types? Or maybe that's only if you're writing Dependent Haskell - but then I worry that we're heading for a fork in the language, which is something we specifically try to avoid.
Cheers Simon
On Tue, 14 Jul 2026 at 18:58, Jakob Brünker <[1]jakob.bruenker@gmail.com> wrote:
Hi all,
Our own Jaro Reinders, based on a proposal originally by Artyom Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn users when the same name appears in the term namespace and type namespace:
[2] https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/pro posals/0000-pun-warnings.rst
These warnings would not be enabled by default, but would bring us a step forward on the path outlined by the accepted proposal #378 (Support the design for dependent types, [3]https://github.com/ghc-proposals/ghc-proposals/pull/378), by supporting writing code in a way that plays well with the principles described in that proposal (i.e. the lexical scoping principle and syntactic unification principle).
They are also a good match for the recently introduced `-XNoListTuplePuns`, which already lets users avoid puns for some builtin types. Any users of `-XNoListTuplePuns` will likely want something along the lines of this proposal.
I left some comments on the github thread but I think they are small enough that they don't have to prevent us from voting on it.
I recommend we accept.
Please indicate whether you wish to accept this proposal.
Jakob
_______________________________________________ ghc-steering-committee mailing list -- [4]ghc-steering-committee@haskell.org To unsubscribe send an email to [5]ghc-steering-committee-leave@haskell.org
References
1. mailto:jakob.bruenker@gmail.com 2. https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0... 3. https://github.com/ghc-proposals/ghc-proposals/pull/378 4. mailto:ghc-steering-committee@haskell.org 5. mailto: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
_______________________________________________ ghc-steering-committee mailing list -- ghc-steering-committee@haskell.org To unsubscribe send an email to ghc-steering-committee-leave@haskell.org
Well, I think this is indeed on the fence. Because this might indeed produce pressure on libraries to offer APIs without punning. It might push people to prefer libraries not using it or rewrite code to not use punning. And this might push unneeded breakage on people who don’t care for DH. I think I am actually in favor of the community deciding to not do that, e.g. just offer punning free pattern aliases or similar. But I think base does this well, there you can use `[a]` or `List a` in your code and since they are just type aliases you stay completely compatible with everything. You can in theory mix them in the same type signature. Best Malte On 2026-07-22 11:35, Simon Marlow wrote:
On Wed, 22 Jul 2026 at 11:26, Malte Ott <[1]malte.ott@maralorn.de> wrote:
I feel like there are three options here:
a) risk the fork b) drop the lexical scoping principle and use type directed resolution like Agda does c) give up on syntactic unification (and thus a major part of DH.)
I don’t think this would be a terrible fork. And it is just a warning. There are actually a lot of warnings and rules that I enforce in my codebases which other projects don’t adhere to. When codes from differents sides of the fork meet in one module there is always an escape hatch.
Stylistic forks are fine, indeed I'm sure we all have our own set of favourite warnings. That's why some warnings are not in -Wall.
If this is just a stylistic fork then OK - I'm not familiar with all the subtleties here, happy to be informed.
Cheers Simon
Best Malte
On 2026-07-22 11:03, Simon Marlow wrote: > On the one hand this is just a warning and not enabled by default, so > its impact is small. > > On the other hand, I worry about the direction of travel here. Is the > long term plan that we will stop using puns? So no more [a] and (a,b) > types? Or maybe that's only if you're writing Dependent Haskell - but > then I worry that we're heading for a fork in the language, which is > something we specifically try to avoid. > > Cheers > Simon > > On Tue, 14 Jul 2026 at 18:58, Jakob Brünker > <[1][2]jakob.bruenker@gmail.com> wrote: > > Hi all, > > Our own Jaro Reinders, based on a proposal originally by Artyom > Kuznetsov, proposes to introduce `-Wpuns` and `-Wpun-bindings`, to warn > users when the same name appears in the term namespace and type > namespace: > > [2][3]https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnin gs/pro > posals/0000-pun-warnings.rst > > These warnings would not be enabled by default, but would bring us a > step forward on the path outlined by the accepted proposal #378 > (Support the design for dependent types, > [3][4]https://github.com/ghc-proposals/ghc-proposals/pull/378), by > supporting writing code in a way that plays well with the principles > described in that proposal (i.e. the lexical scoping principle and > syntactic unification principle). > > They are also a good match for the recently introduced > `-XNoListTuplePuns`, which already lets users avoid puns for some > builtin types. Any users of `-XNoListTuplePuns` will likely want > something along the lines of this proposal. > > I left some comments on the github thread but I think they are small > enough that they don't have to prevent us from voting on it. > > I recommend we accept. > > Please indicate whether you wish to accept this proposal. > > Jakob > > _______________________________________________ > ghc-steering-committee mailing list -- > [4][5]ghc-steering-committee@haskell.org > To unsubscribe send an email to > [5][6]ghc-steering-committee-leave@haskell.org > > References > > 1. mailto:[7]jakob.bruenker@gmail.com > 2. [8]https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/ proposals/0000-pun-warnings.rst > 3. [9]https://github.com/ghc-proposals/ghc-proposals/pull/378 > 4. mailto:[10]ghc-steering-committee@haskell.org > 5. mailto:[11]ghc-steering-committee-leave@haskell.org
> _______________________________________________ > ghc-steering-committee mailing list -- [12]ghc-steering-committee@haskell.org > To unsubscribe send an email to [13]ghc-steering-committee-leave@haskell.org
_______________________________________________ ghc-steering-committee mailing list -- [14]ghc-steering-committee@haskell.org To unsubscribe send an email to [15]ghc-steering-committee-leave@haskell.org
References
1. mailto:malte.ott@maralorn.de 2. mailto:jakob.bruenker@gmail.com 3. https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/pro 4. https://github.com/ghc-proposals/ghc-proposals/pull/378 5. mailto:ghc-steering-committee@haskell.org 6. mailto:ghc-steering-committee-leave@haskell.org 7. mailto:jakob.bruenker@gmail.com 8. https://github.com/ghc-proposals/ghc-proposals/blob/pun-warnings/proposals/0... 9. https://github.com/ghc-proposals/ghc-proposals/pull/378 10. mailto:ghc-steering-committee@haskell.org 11. mailto:ghc-steering-committee-leave@haskell.org 12. mailto:ghc-steering-committee@haskell.org 13. mailto:ghc-steering-committee-leave@haskell.org 14. mailto:ghc-steering-committee@haskell.org 15. mailto:ghc-steering-committee-leave@haskell.org
participants (8)
-
Adam Gundry -
Erik de Castro Lopo -
Jakob Brünker -
Malte Ott -
Matthías Páll Gissurarson -
Sebastian Graf -
Simon Marlow -
Simon Peyton Jones