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