[ghc-steering-committee] Proposal #270: Support pun-free code. Recommendation: accept

[Chris Dornan]

Hi all, I have been assigned to shepherd Proposal #270: Support pun-free code

Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md 
Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270

The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors.

It introduces -Wpuns and -Wpun-bind to warn about puns at usage and binding sites, respectively, and adds qualified import syntax for importing selectively into the data and type name spaces:

  import Data.Proxy type qualified as T   -- import only the type namespace
  import Data.Proxy data qualified as D   -- import only the data namespace

As the low number indicates the proposal has been around for a while and the author has an implementation PR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044.

The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565. (See Simon’s comment at the link for an explanation of the Haskell language fork idea.)

There is a long tradition of using data/type constructor puns (older than Haskell itself) and many people will consider it good style (I certainly do), while others do not, and they will benefit from tools to help manage and limit their use. So, notwithstanding the fork-like nature of the proposal, because it is not very intrusive (some warnings with finer control of qualified imports), and it is helping folks to establish a subset that they are maintaining anyway, I am minded to accept this proposal — though it was close.

My sole concern is that it could give rise to contentious pressure on the wider Haskell community to embrace the subset. To (avoiding) this end, I suggest that we include wording in the user guide section documenting this extension to the effect that there is no consensus on the desirability or otherwise of the punful code the extension seeks to address.

Chris