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