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 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 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-de... 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 mailto:chris@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 mailto:mail@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 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-de... https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-de... 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

It certainly won’t be easy to build the required consensus, it will almost certainly take time, and we will have to work with other groups with more reach and capacity for this kind of activity. Does anybody else believe that building consensus around disruptive changes is not something Haskell technical committees should attempt? If so please speak up.

On 3 Sep 2022, at 09:58, Joachim Breitner wrote:

So the question is: How can we build wider consensus? What does it even mean?

Is this committee a place to establish consensus? Or reddit? Or a session at Haskell Symposium? Or is consensus something that is structurally not possible to build and recognize?

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 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 mailto:chris@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 mailto:lists@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 mailto:chris@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 mailto:mail@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 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-de... https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-de... 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I'm mildly in support of this proposal. Personally, I don't care much for data constructor punning. Haskell is the only language I use them in. But I do use them in Haskell. Because it's become some sort of a norm (and since it's one fewer name to conjure, it's definitely an attractive option). Honestly, I can't really imagine a future of Haskell without puns. But things can change very quickly. Chris, you're speaking about building consensus. Having optional warnings like these can be a good way to help discover what the consensus is: it gives tools to the reformists to try their ideas out and try to convince the rest of the community. Maybe the documentation should explicitly mention that turning on these warnings is not a recommendation from the language's authors. It is a tool to support a particular style that some find useful. But, then again, I'm not going to champion this proposal either. /Arnaud On Mon, Sep 5, 2022 at 9:56 AM Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

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 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 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 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 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 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 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-de... 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

To be clear, I'm quite happy with us saying that we are not trying to police style. Indeed I'm not! Some people might find this statement in contradiction with my earlier

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.

Note that "style" does not occur in that sentence, nor does it say anything about what users write. That statement is all about how the steering committee will steer and how we might evaluate future proposals. Maybe we don't favor the statement -- Simon's points about needlessly irritating people are good. I personally like clear statements like mine quoted one above (or "We're not policing style"), but I recognize that strategic ambiguity has its place. Maybe the high-level bit here -- the one we might all agree on and be able to move forward with -- is to say loudly that the GHC Steering Committee is utterly agnostic on Haskell style, and we continue to encourage our users to develop, experiment, and have fun with the full range of programs GHC accepts. Richard

On Sep 5, 2022, at 8:42 AM, Chris Dornan wrote:

I agree entirely — these tools might help with discovering if such a wider consensus could be built.

...

On 5 Sep 2022, at 09:32, Spiwack, Arnaud mailto:arnaud.spiwack@tweag.io> wrote:

I'm mildly in support of this proposal.

Personally, I don't care much for data constructor punning. Haskell is the only language I use them in. But I do use them in Haskell. Because it's become some sort of a norm (and since it's one fewer name to conjure, it's definitely an attractive option). Honestly, I can't really imagine a future of Haskell without puns. But things can change very quickly.

Chris, you're speaking about building consensus. Having optional warnings like these can be a good way to help discover what the consensus is: it gives tools to the reformists to try their ideas out and try to convince the rest of the community.

Maybe the documentation should explicitly mention that turning on these warnings is not a recommendation from the language's authors. It is a tool to support a particular style that some find useful.

But, then again, I'm not going to champion this proposal either.

/Arnaud

On Mon, Sep 5, 2022 at 9:56 AM Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: 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 mailto:chris@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 mailto:simon.peytonjones@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 mailto:chris@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 mailto:lists@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 mailto:chris@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 mailto:mail@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 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-de... https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-de... 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hi, Am Mittwoch, dem 07.09.2022 um 22:56 +0100 schrieb Simon Peyton Jones:

...

Maybe the high-level bit here -- the one we might all agree on and be able to move forward with -- is to say loudly that the GHC Steering Committee is utterly agnostic on Haskell style, and we continue to encourage our users to develop, experiment, and have fun with the full range of programs GHC accepts.

Great -- we could add that to our guidance on the GHC proposals site 

But such a statement does seem to contradict "That statement is all about how the steering committee will steer and how we might evaluate future proposal".  If we say we will look on pun-free proposals more favourably than pun-ful ones, that does seem to be leaning on the "style" scales, doesn't it?    Is that compatible with being "utterly agnostic" about style?

I’d also be hesitant to promise to never judge proposals by “style”.  Removal of NPlusKPatter certainly was a strong statement that this was bad style (predating the committee, but still). Discouraging partiality in the language and the libraries, as is happening on various fronts at the moment (e.g. partial selectors, but also various CLC discussions) seem to say that “writing Haskell with partial building blocks is bad style”. And in this vain I wouldn’t rule out the committee preferring proposals that work well in code that follows a style that makes Dependent Haskell work smoothly (e.g., accept #270, but reject a the hypothetical `newtype Age <- Int` proposal). (Maybe this isn’t really style but something else, and I misunderstand what’s said in this thread.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Yes, I originally asked for just such a statement — if we could agree to add such a statement to the notes for the extension then my concerns would be met. I am also keen to support DH development and, if you want to establish pun-free code bases, I think these tools would be useful — so if we could get clarity on this I would be tempted to support it again.

On 5 Sep 2022, at 08:57, Simon Peyton Jones wrote:

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 mailto:chris@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 mailto:simon.peytonjones@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 mailto:chris@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 mailto:lists@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 mailto:chris@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 mailto:mail@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 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-de... https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0378-de... 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@joachim-breitner.de mailto:mail@joachim-breitner.de http://www.joachim-breitner.de/ http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee