ghc-steering-committee

Download

ghc-steering-committee@haskell.org

December 2022

8 participants
11 discussions

Proposal #270: Support pun-free code. Recommendation: accept
by Chris Dornan 08 Dec '22

08 Dec '22

Hi all, I have been assigned to shepherd 'Proposal #270: Support pun-free code’ and this is my second attempt to reach a conclusion (see below for for my original encapsulation of the proposal). As I said, my outstanding concern was that some could see this proposal as a green-lighting a general move against the use of these puns in general Haskell code as ‘bad style. The author has now clarified in the proposal that it should not be seen in this light. Unless anyone has any outstanding objections I suggest the we accept the proposal — or at least hold an up-and-down vote to resolve whether we are going to accept the proposal or not. I vote yes to accepting this proposal. Chris — My original summary: Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… <https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support…> Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270 <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 <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-536115… <https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115…>. (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.

4 7