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

[Simon Peyton Jones]

I gave my own reaction here on the discussion thread
<https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-1225337441>
.

Simon

On Fri, 2 Sept 2022 at 17:54, Richard Eisenberg <lists at richarde.dev> wrote:

> I'm both in favor of accepting this proposal and in favor of setting a
> direction for GHC and the language it compiles.
>
> I think the second is more contentious than the first, so I'll start
> there: We comprise the GHC Steering Committee. And thus we should steer!
> That is, we should make decisions that all work together in pursuit of a
> goal. We have not spent much time (and I do not propose doing it now)
> crisply defining that goal, but #378 and my more recent Principles document
> is an attempt to bring in that higher level structure to our
> decision-making process. I am thus comfortable with recommending, as a
> committee, that future code avoid puns.
>
> However, that stops short of several steps we might take:
>  - I do *not* recommend turning on -Wpuns or -Wpun-binds by default or in
> -Wall.
>  - I do *not* recommend ever planning to remove support for punning code.
>  - I do *not* recommend reaching out to developers telling them to update
> what they have written.
>  - I do *not* recommend ever calling punning code "old fashioned" or
> other derogatory descriptions.
>
> Instead, I recommend stating that GHC will be following a course
> increasing support for pun-free code, and not putting effort into improving
> (only) punned code. For example, perhaps someone will write a proposal
> introducing a new syntax `newtype Age <- Int`, which would automatically
> use the type name as the constructor name. In a world with puns, this
> syntax might have some advantages. However, given our course away from
> puns, we would likely quickly reject such a proposal, as out-of-keeping
> with our overall direction. (Note: "likely". If a new proposal came along
> that offered great benefits but only with puns, then maybe we would still
> accept!)
>
> In keeping with this general direction, some developers may choose to
> avoid puns. That is their choice, not forced on them by us, but made with
> the knowledge of where we are heading. Other developers will continue to
> use puns, and that's fine, too.
>
> Back to this specific proposal: Given that we accepted #378 -- and I still
> support the decision to do so -- I think we should accept #270, as well.
>
> Richard
>
> On Aug 24, 2022, at 7:46 AM, Chris Dornan <chris at chrisdornan.com> wrote:
>
> I don’t think we should be in the business of overturning by fiat
> significant conventions that have been long established.
>
> I am really quite concerned about people pointing to proposals accepted by
> a technical committee and expanding this into wide-ranging normative
> conventions to be imposed on the general Haskell community after the fact.
>
> Accordingly I am flipping my recommendation. I now agree with Simon. Until
> we are satisfied that the wider consensus has been established — that these
> puns are no longer good style — I think we should *not* accept this
> proposal. The risks are too great and, as Simon points out, the potential
> benefits are not compelling.
>
> Chris
>
>
> On 2022-08-24, at 11:49, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> thanks for the summary.
>
> Am Mittwoch, dem 24.08.2022 um 07:27 +0100 schrieb Chris Dornan:
>
> 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.
>
>
> I wonder if it isn’t really on us to address that and try to establish
> a consensus about where we want Haskell to evolve to? Should we not try
> to provide unifying guidance by choosing between
>
>  puns are fine and good practice, the language evolution takes that into
>  account
>
> and
>
>  puns are discouraged and undesirable, as they do not work smoothly with
>  the Haskell we envision for the future,
>  we provide work-arounds (like this proposal) when dealing with code
>  that still has them
>
> It seems that by accepting
> https://github.com/ghc-proposals/ghc-proposals/pull/378 we went down
> the second road, although the wording in that proposal, in section
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-dependent-type-design.rst#non-design-of-dependent-types
> is much more diplomatic than I was above.
>
> Maybe the sentiment could be that puns are a bit like lazy IO: It used
> to be the thing to do so, it will continue to work, but they should no
> longer be considered current good practice.
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
> mail at joachim-breitner.de
> http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> 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/20220902/64ad077f/attachment-0001.html>