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

[Richard Eisenberg]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220902/3e26f2d1/attachment.html>