<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I'm in support. I'm supporting this proposal so that Haskell can be a friendly home both for those who like punning and those who don't. I'm not taking a position on which is "better", but I don't want to stand in the way of those who do have a view and want to write in that style.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Dec 2022 at 18:33, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><span style="color:rgb(0,0,0)">Hi all, </span><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#000000"><span>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).</span></font></div><div><font color="#000000"><span><br></span></font></div><div><font color="#000000">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.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">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.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">I vote yes to accepting this proposal.</font></div><div><font color="#000000"><br></font></div><div><font color="#000000">Chris</font></div><div><font color="#000000"><br></font><div>—</div><div><br></div><div>My original summary:</div><div><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">Proposal text: </span><a href="https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md" target="_blank">https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support-pun-free-code.md</a><span style="color:rgb(0,0,0)"> </span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">Proposal discussion: </span><a href="https://github.com/ghc-proposals/ghc-proposals/pull/270" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/270</a><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors.</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">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:</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)"> import Data.Proxy type qualified as T -- import only the type namespace</span><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)"> import Data.Proxy data qualified as D -- import only the data namespace</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">As the low number indicates the proposal has been around for a while and the author has an implementation PR: </span><a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044</a><span style="color:rgb(0,0,0)">.</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: </span><a href="https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115565</a><span style="color:rgb(0,0,0)">. (See Simon’s comment at the link for an explanation of the Haskell language fork idea.)</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">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.</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><span style="color:rgb(0,0,0)">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.</span><br style="color:rgb(0,0,0)"><br style="color:rgb(0,0,0)"><br></div></div></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>