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