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

[Simon Peyton Jones]

>
> I remain against the proposal because it seems to be generating a lot of
> confusion on this point.
>

Maybe your opposition would be mitigated by a clear statement that we *aren't
*trying to police style?  Rather, we are trying to create a language in
which authors can (if they wish) check adherence to a particular style
using suitable warning flags -- but are by no means required to do so.

I'm keen to allow the DH train to continue unimpeded, because I think it
has lots of potential.  But I don't think that's incompatible with others
to continue punning unimpeded.

Simon

On Sun, 4 Sept 2022 at 08:21, Chris Dornan <chris at chrisdornan.com> wrote:

> For sure, the proposed tools are not in themselves likely to provide an
> immediate problem — for a while I was marginally in favour of the proposal.
> The contentious issue concerns the style the tools are clearly intended to
> police.
>
> If everyone agrees that use of puns is a matter of style and we are not in
> the business of policing style, nor trying to eliminate puns from the
> language, then that is fine by me — it certainly is the safest course of
> action and doesn’t require any shifts of long established patterns and
> habits.
>
> My original recommendation was to simply make it clear in the notes that
> there was no attempt establish a preferred style but that clarification was
> opposed on the grounds that some saw this as part of a general move against
> puns.
>
> I remain against the proposal because it seems to be generating a lot of
> confusion on this point.
>
> Chris
>
>
> On 3 Sep 2022, at 19:46, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Believe me, these are serious Haskellers. And they do not appreciate being
>> contemptuously treated like pawns by various Haskell technical committees
>> that unilaterally decide the future of Haskell and impose it on them after
>> the fact, especially where significant disruption is involved.
>>
>
> I don't think this is as big a deal as everyone is making out.
>
> All this proposal does is
>
>    - Add a new, more selective import, so you can import just the type or
>    just the value, namespace.
>    - Add a couple of warnings
>
> That does not seem to treat anyone with contempt, does it?
>
> 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
>>
>
> I worry that making an explicit statement like this would simultaneously
> (a) have little practical effect on our future decisions, but (b) risk
> making a constituency feel aggrieved in the way that Chris suggests.  That
> would be a bad outcome: irritated consumers but little payoff!  I don't see
> a need to make an explicit decision of this kind.  (I didn't find Richard's
> for-instance compelling.)  Let's jump this bridge when we come to it.
>
> That has the merit (in terms of time and effort) that we don't have to
> "establish a consensus".  I'm unclear what precisely is the issue about
> which consensus is advocated, but I think it's to do with programming
> style.  Richard says "And thus we should steer".   But I'm not sure that we
> should, at least on programming style.  Haskell has some very clear (and
> entirely un-controversial) unifying principles: purity, and static typing.
> But, in contrast, it does *not *have a very clear stance on programming
> style.  We have guards, let and where, case, \case and \cases, sections,
> comprehensions etc etc.  That allows different programming styles, and I
> don't feel a need to steer towards, let alone impose, a "blessed" style.
> Let's just accomodate a diversity of opinion.
>
> Simon
>
> On Sat, 3 Sept 2022 at 00:30, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> To be clear, if we could go back 35 years and explain to the first
>> Haskell language committee the value of outlawing puns I would be in favour
>> of doing this. If we were in a situation where the community were aware of
>> the problems and there was a broad consensus on the desirability of moving
>> away from puns and on the chosen path then I would be in favour of setting
>> our policy and providing the tools to help that evolution — like the ones
>> described by this very proposal.
>>
>> But we are not in this situation. Normally GHC is in a strong position to
>> lead Haskell in new directions — we are careful to propose non-disruptive
>> evolution that folks can opt into and trial. In this way the community can
>> try things out and build a consensus on what is useful or not. This is why
>> I am an enthusiastic proponent of our language extensions and this very
>> proposal process. In my view it is the engine that has not just driven
>> Haskell but arguably wider evolution of practical programming languages.
>> The problem is that what we are proposing to do here is extremely
>> disruptive, made significantly worse by the increased dependence of modern
>> Haskell on newtypes. I can readily accept that everyone involved in this
>> list has long viewed puns as an unfortunate Haskell mistake, bad style and
>> long given up the practice of using them, if they ever did. But this
>> represents a very particular subset of the Haskell community with a
>> distinct set of concerns to the wider community. Many of those are serious
>> users of Haskell in their work and others (with strong overlap) with
>> immense commitment to developing and maintaining packages that are the life
>> blood of the ecosystem (GHC being the heart in this metaphor).
>>
>> Believe me, these are serious Haskellers. And they do not appreciate
>> being contemptuously treated like pawns by various Haskell technical
>> committees that unilaterally decide the future of Haskell and impose it on
>> them after the fact, especially where significant disruption is involved.
>> Handled wrongly it would be really easy to see significant pushback
>> developing in the community along the lines we saw with the PVP, and before
>> we know it we will find ourselves in another decade of a debilitating tech
>> culture war.
>>
>> (This is all expressed in stark terms, but I am following the
>> precautionary principle — I do believe the risks to be significant but this
>> kind of thing is difficult to predict.)
>>
>> If I could be sure that we were living in Richard’s world I would be
>> entirely happy to follow the plan he is advocating. My concern is simply
>> that without extreme care its subtly will be quickly lost and we will see
>> polarisation. This is not a technical problem so much as a social one that
>> can only be safely navigated with skilful communication.
>>
>> I would advocate that we advertise that we would like Haskell to evolve
>> away from the puns of this proposal and make it clear that we accept that
>> that is not where Haskell is and request feedback and help on how we can
>> start building a roadmap to pun-free Haskell — assuming we can build the
>> wider consensus that this is desirable (which hopefully we can, but we
>> should try to avoid being presumptuous).
>>
>> Until we can establish consensus on how this is going to all be
>> communicated I remain in favour of keeping this proposal in stasis.
>>
>> I would like to think I am merely unpacking Simon’s position...
>>
>> Chris
>>
>>
>>
>> On 2 Sep 2022, at 17:53, 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/20220905/74ac3aa3/attachment-0001.html>