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

[Simon Peyton Jones]

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.

Simon

On Mon, 5 Dec 2022 at 18:33, Chris Dornan <chris at chrisdornan.com> wrote:

> 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-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.
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221205/4337a7b8/attachment-0001.html>