From lists at richarde.dev  Fri Sep  2 16:35:40 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 2 Sep 2022 16:35:40 +0000
Subject: [ghc-steering-committee] Proposal #522: Or patterns.
 Recommendation: accept
In-Reply-To: <A24C9665-FBDA-4034-B7BF-6C563A1BB67E@chrisdornan.com>
References: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com>
 <CAJKmMz9W0q8350K4b_8gyhwB20ktucgHh_DdBnKzdDQ=vdcsMg@mail.gmail.com>
 <A24C9665-FBDA-4034-B7BF-6C563A1BB67E@chrisdornan.com>
Message-ID: <010f0182ff0ede6c-9a73eb18-6238-42a2-b54a-f27d44de0e0d-000000@us-east-2.amazonses.com>

Any other thoughts here? I plan to accept next week.

Thanks,
Richard

> On Aug 24, 2022, at 7:49 AM, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> Count me in — yes to Or patterns for me.
> 
>> On 2022-08-24, at 11:57, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> 
>> I'm mildly in favour of acceptance.  One more thing.  But a reasonably easy thing.
>> 
>> Simon
>> 
>> On Fri, 19 Aug 2022 at 22:23, Richard Eisenberg <lists at richarde.dev> wrote:
>> Hi all,
>> 
>> I have been assigned to shepherd Proposal #522, Or patterns.
>> 
>> Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst
>> Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522
>> 
>> The proposal introduces a syntax for or-patterns. Here is an example:
>> 
>> case ... of
>>  K1 a b c -> Just ...
>>  K2 d e -> Just ...
>>  (K3 {} ; K4 {} ; K5 {}) -> Nothing
>> 
>> Summary
>> 
>> Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages.
>> 
>> The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patterns.rst#id12) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax.
>> 
>> The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern.
>> 
>> Two implementors are named in the proposal.
>> 
>> Recommendation
>> 
>> I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension.
>> 
>> (*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this.
>> 
>> The downsides are:
>> - Yet another feature to think about, including a new extension name.
>> - Yet another feature to implement and maintain.
>> 
>> I think the improvements to the language are worth these downsides, though I could be convinced otherwise.
>> 
>> Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection.
>> 
>> Thanks!
>> Richard
>> _______________________________________________
>> 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
> 


From lists at richarde.dev  Fri Sep  2 16:53:59 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 2 Sep 2022 16:53:59 +0000
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
Message-ID: <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>

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>

From simon.peytonjones at gmail.com  Fri Sep  2 19:23:50 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 2 Sep 2022 20:23:50 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz_iSCFNQ6Q8wJHPWAfD7XDSfETTruO-Ggs=BjcXW4=bBQ@mail.gmail.com>

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>

From chris at chrisdornan.com  Fri Sep  2 23:30:29 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Sat, 3 Sep 2022 00:30:29 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
Message-ID: <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>

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 <mailto: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 <mailto: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 <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 <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 <mailto: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/20220903/441fab79/attachment.html>

From mail at joachim-breitner.de  Sat Sep  3 04:31:29 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 03 Sep 2022 06:31:29 +0200
Subject: [ghc-steering-committee] Please review #512: NoFieldSelectors as
 datatype annotation, Shepherd: Baldur
Message-ID: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>

Dear Committee,

NoFieldSelectors as datatype annotation
have been proposed by Matt Parsons

https://github.com/ghc-proposals/ghc-proposals/pull/512

https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scoped/proposals/0512-nofieldselectors-per-datatype.md

I suggest Baldur to shepherd this proposal.

Please guide us to a conclusion as outlined in 
https://github.com/ghc-proposals/ghc-proposals#committee-process

Thanks,
Joachim



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From mail at joachim-breitner.de  Sat Sep  3 08:58:30 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 3 Sep 2022 08:58:30 +0000 (UTC)
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
Message-ID: <bf204ce4-e65b-4d72-bf23-4b6668d32dee@joachim-breitner.de>

Hi,

> assuming we can build the wider consensus that this is desirable

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?

Genuine questions, as I don't have answers here.

Cheers,
Joachim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220903/8301c839/attachment-0001.html>

From chris at chrisdornan.com  Sat Sep  3 10:54:09 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Sat, 3 Sep 2022 11:54:09 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <bf204ce4-e65b-4d72-bf23-4b6668d32dee@joachim-breitner.de>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <bf204ce4-e65b-4d72-bf23-4b6668d32dee@joachim-breitner.de>
Message-ID: <0C34144E-6EEA-4B99-B0C7-6E3CD8239DA0@chrisdornan.com>

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 <mail at joachim-breitner.de> 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? 

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

From simon.peytonjones at gmail.com  Sat Sep  3 18:46:27 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 3 Sep 2022 19:46:27 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
Message-ID: <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>

>
> 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/20220903/25dbc8e0/attachment.html>

From chris at chrisdornan.com  Sun Sep  4 07:21:11 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 4 Sep 2022 08:21:11 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
Message-ID: <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto:mail at joachim-breitner.de>
>>>> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>>>> 
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20220904/fdd2776f/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Sep  5 07:57:39 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 5 Sep 2022 08:57:39 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
Message-ID: <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>

>
> 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>

From arnaud.spiwack at tweag.io  Mon Sep  5 08:32:35 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 5 Sep 2022 10:32:35 +0200
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
Message-ID: <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>

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 at 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 <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
>>>
>>
>> _______________________________________________
> 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/c9e6ba80/attachment-0001.html>

From arnaud.spiwack at tweag.io  Mon Sep  5 09:47:50 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 5 Sep 2022 11:47:50 +0200
Subject: [ghc-steering-committee] Please review #500: Add implicit
 import proposal, New Shepherd: Simon M.
In-Reply-To: <010f0182f5eb4fd1-f3e2f9b0-6f6c-4c1b-abbb-e0782a6367ff-000000@us-east-2.amazonses.com>
References: <035c69c81b6fe9921600c053e2ee919b62e1837a.camel@joachim-breitner.de>
 <5ef21ee8fbe9a215b87efcb56cec578a22399200.camel@joachim-breitner.de>
 <CANsrgP+k0wOOkJeFapeJQejqw6gVNFjwrjMR+E1nVjCkbQGR4w@mail.gmail.com>
 <44fdf8fa0e53a0704339da2086f40353ee07cc87.camel@joachim-breitner.de>
 <5eea0371-7de1-4a4d-92d9-870e73768683@www.fastmail.com>
 <CANsrgPKnwpqge-M1f67jmNOoB2S4cv8nnFemD4uOwnt_dBLBKw@mail.gmail.com>
 <CANsrgP+hx4+sDfH_qDSt6Ry4eB_tagSgK2xrjq02B1FdrPvLUQ@mail.gmail.com>
 <010f0182f5eb4fd1-f3e2f9b0-6f6c-4c1b-abbb-e0782a6367ff-000000@us-east-2.amazonses.com>
Message-ID: <CAH6fHQnsRWjuHawJ_sGJinHs+K1bkEqVOHghNc=Fgr34Od6cnA@mail.gmail.com>

On my end, I think that implementing this proposal with a warning, à la
Eric's (2) is an absolutely decent option.

That being said, it's not a tremendously useful feature either. It's not
the odd `Debug.Trace` that costs much time. Imports in Haskell are costly
because they are too fine-grained. Therefore import statement lists are
really long, and you will spend a lot of time managing them (it's in
particular a non-trivial impediment to inter-module refactorings). This
proposal doesn't address this sort of situation.

So the value of this proposal is probably very small, if the cost of
implementing this proposal is non-trivial, then it's probably not worth
going for it.

On Thu, Sep 1, 2022 at 12:00 AM Richard Eisenberg <lists at richarde.dev>
wrote:

> Just because it's paged in now: I, too, am on the fence. But I want to
> vote against warning at every implicit import, because I often develop with
> -Werror on. If the whole point of this is to enable Debug.Trace.trace, then
> I've lost the benefit.
>
> I'm attracted by the idea of leaning more heavily on external tooling. For
> example, we can imagine a command-line option that specifies an `import`
> statement. Tooling can generate the right such options. That would seem to
> be better than making this a language feature, because an external tool is
> in a better position to know e.g. how to disambiguate if there are multiple
> X.Y modules available from different packages.
>
> Richard
>
> On Aug 31, 2022, at 3:13 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Anyway, for what it's worth the proposer has asked to mark the proposal
> dormant until the compile-time performance issues can be resolved.
>
> Thanks everyone for the discussion, we can revisit this if/when the
> proposal wakes up again.
>
> Cheers
> Simon
>
> On Wed, 31 Aug 2022 at 20:07, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I just checked the proposal and in fact, Eric's 1a option below is what
>> is being proposed. That is, implicit imports don't bring any new instances
>> into scope.
>>
>> For me I don't think that actually simplifies things though. Because now,
>> we have a difference in semantics between using an implicit import and an
>> explicit import, and a weird corner case that will surprise people.
>>
>> I'm somewhat attracted by option 2, warning about implicit imports. If
>> this is supposed to be a convenience feature during development, I could
>> see that being useful. In a similar vein, I suggested on github that
>> implicit imports could work only for modules outside the current package,
>> which avoids a lot of the implementation complexity because we don't have
>> to extract implicit imports to perform dependency analysis. As a language
>> feature I think that's a terrible design, but as a productivity tool during
>> development it makes some sense - rather like the intention behind the
>> existing hacky feature  in GHCi that the whole proposal is inspired by.
>> But do we actually want that kind of feature? I'm still not sure really.
>>
>> Cheers
>> Simon
>>
>> On Mon, 29 Aug 2022 at 18:00, Eric Seidel <eric at seidel.io> wrote:
>>
>>> If the main benefit we expect from this feature is improved development
>>> productivity (from not having to jump around to insert temporary imports),
>>> I can think of two ways to restrict the feature to keep most of the benefit
>>> without dealing with tricky questions like instance imports.
>>>
>>> 1a. Never import instances via an implicit import. This limits the
>>> usefulness somewhat if you're trying to use an overloaded method, because
>>> you might depend on the instances that would come alongside the method.
>>> But, it's an easy rule to remember, and our goal is to improve dev
>>> productivity, not provide a production-grade solution.
>>>
>>> 1b. Always import instances via an implicit import. Same argument as
>>> above, but perhaps more friendly to productivity.
>>>
>>> 2. Always warn about implicit imports so they mostly stay out of
>>> production builds.
>>>
>>> On Mon, Aug 29, 2022, at 11:19, Joachim Breitner wrote:
>>> > Hi Simon,
>>> >
>>> > thanks for picking this up.
>>> >
>>> > I am similarly torn.
>>> >
>>> > Everytime I have to add and then remove Debug.Trace from my import list
>>> > I am annoyed. And especially for quick scripts etc. having less red
>>> > tape to go through seems to be an improvement. So I see the benefit. If
>>> > I’d be creating a programming language afresh, I might be inclined to
>>> > allow that – a qualified identifier is already quite explicit, after
>>> > all!
>>> > (I admit that I still don’t use the latest tooling available, maybe
>>> > someone using LSP for all their Haskell uses might have a different.)
>>> >
>>> > On the other hand, this is not a fresh programming language, we have
>>> > lived okish without this so far, and in particular the behavior with
>>> > regard to instances might be sufficient reasons to reject this –
>>> > although not without some regret.
>>> >
>>> >
>>> > 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
>
>
> _______________________________________________
> 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/85b863fa/attachment.html>

From chris at chrisdornan.com  Mon Sep  5 12:39:06 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 5 Sep 2022 13:39:06 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
Message-ID: <CB8D4E84-CB1F-43B6-A898-8AC02660A727@chrisdornan.com>

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 <simon.peytonjones at 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 <chris at chrisdornan.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto:mail at joachim-breitner.de>
>>>>> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/97e128bb/attachment-0001.html>

From chris at chrisdornan.com  Mon Sep  5 12:42:53 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 5 Sep 2022 13:42:53 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
 <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
Message-ID: <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>

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 <arnaud.spiwack at 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 <simon.peytonjones at gmail.com <mailto:simon.peytonjones at 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 <chris at chrisdornan.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto:mail at joachim-breitner.de>
>>>>> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>>>>> 
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/6cf9e55f/attachment-0001.html>

From lists at richarde.dev  Wed Sep  7 11:34:45 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 7 Sep 2022 11:34:45 +0000
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
Message-ID: <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>

I also lean toward acceptance.

However, I'm a little worried about the flourishing of warnings not in -Wall. Ignoring -Weverything -- which tends to be over the top, even for the paranoid -- all of the extra warnings have to be enabled independently. Does it make sense to try to bring some structure to this area? Or maybe we say "no" and leave it to IDEs to impose that structure. Actually, I've already argued myself into that latter camp.

In any case, I vote to accept this proposal.

Richard

> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance.
> 
> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> Dear Committee,
> 
> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in
> 
> ```
> data T = T1 { x :: Int, y :: Bool }
>        | T2 { y :: Bool }
> ```
> 
> The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`).
> 
> I recommend acceptance.
> 
> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516 <https://github.com/ghc-proposals/ghc-proposals/pull/516>
> 
> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
> > Dear Committee,
> >
> > Introduce `-Wincomplete-record-selectors`
> > have been submitted by Adam Gundry
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/516 <https://github.com/ghc-proposals/ghc-proposals/pull/516>
> > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst <https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst>
> >
> > I suggest that Eric shepherds this proposal.
> >
> > Please guide us to a conclusion as outlined in 
> > https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> >
> > Thanks,
> > Joachim
> >
> > -- 
> > Joachim Breitner
> >   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> >   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 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/20220907/ef2eb79a/attachment.html>

From lists at richarde.dev  Wed Sep  7 11:53:52 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 7 Sep 2022 11:53:52 +0000
Subject: [ghc-steering-committee] Please review: #515 Relaxing HasField
 constraints
In-Reply-To: <CAH6fHQkP7-vD+j=202T6aPHiicjLjXyuv6UUXO5jo5yNB9CShA@mail.gmail.com>
References: <5F4E7390-2196-4FAA-926E-506141F4D487@gmail.com>
 <CAH6fHQkP7-vD+j=202T6aPHiicjLjXyuv6UUXO5jo5yNB9CShA@mail.gmail.com>
Message-ID: <010f018317ccab7f-4611fdc0-cbc2-4d8d-808a-d2f7cdd11adc-000000@us-east-2.amazonses.com>

I have raised what may be an important technical objection: https://github.com/ghc-proposals/ghc-proposals/pull/515#issuecomment-1239289647

I like the spirit of this proposal, but it may be out of reach given my linked post. Curious for others' thoughts -- I hope my objection is ill-founded!

Richard

> On Aug 23, 2022, at 4:54 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> I don't have much of an opinion on this proposal.
> 
> I do believe that, in the current state, it doesn't discuss in sufficient detail about whether instances should be considered coherent or not by the compiler. This seems to be the most non-trivial choice in the proposal. I've asked for an addition to that respect on the Github thread.
> 
> On Wed, Aug 10, 2022 at 12:58 PM Tom Harding <i.am.tom.harding at gmail.com <mailto:i.am.tom.harding at gmail.com>> wrote:
> Hi all,
> 
> Ollie Charles’ proposal <https://github.com/ghc-proposals/ghc-proposals/pull/515> removes the restrictions placed on HasField instances. Close to my heart, this addresses the problem of creating custom `HasField` instances for record types. I’m in favour of this proposal as it would solve some issues I have encountered, but the floor is open for discussion.
> 
> Thanks,
> Tom
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 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/20220907/bcfb67cf/attachment.html>

From lists at richarde.dev  Wed Sep  7 13:05:48 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 7 Sep 2022 13:05:48 +0000
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
 <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
 <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>
Message-ID: <010f0183180e85e5-b389b051-5efc-436e-9866-736b13a829b1-000000@us-east-2.amazonses.com>

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 <chris at chrisdornan.com> 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 <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at 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 <simon.peytonjones at gmail.com <mailto:simon.peytonjones at 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 <chris at chrisdornan.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 <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 <mailto:mail at joachim-breitner.de>
>>>>>> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 at haskell.org <mailto:ghc-steering-committee at 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 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/20220907/d215e1d4/attachment-0001.html>

From simon.peytonjones at gmail.com  Wed Sep  7 21:56:56 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 7 Sep 2022 22:56:56 +0100
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <010f0183180e85e5-b389b051-5efc-436e-9866-736b13a829b1-000000@us-east-2.amazonses.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
 <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
 <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>
 <010f0183180e85e5-b389b051-5efc-436e-9866-736b13a829b1-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9HhA8pxQQJT=7XnX2oRxksz7CfqEfWz8-RFq+7SKR6og@mail.gmail.com>

>
> 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?

To be clear, I'm in favour of accepting the proposal.  Just without an
accompanying policy statement about steering the language into pun-free
waters.

Simon

On Wed, 7 Sept 2022 at 14:06, Richard Eisenberg <lists at richarde.dev> wrote:

> 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 <chris at chrisdornan.com> 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 <arnaud.spiwack at 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 <
> simon.peytonjones at 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 <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
>>>>
>>>
>>> _______________________________________________
>> 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/20220907/8c2ae8ae/attachment-0001.html>

From simon.peytonjones at gmail.com  Wed Sep  7 22:05:43 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 7 Sep 2022 23:05:43 +0100
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>

I'd be happy to accept this one.

In fact I'd prefer it if

   - -wpartial-record-selectors and -wpartial-record-updates were in -Wall
   - But -wpartial-fields should definitely not be in -Wall because there
   is absolutely nothing wrong with using named fields to help with pattern
   matching and record construction -- places were partiality is not an issue

Simon

On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev> wrote:

> I also lean toward acceptance.
>
> However, I'm a little worried about the flourishing of warnings not in
> -Wall. Ignoring -Weverything -- which tends to be over the top, even for
> the paranoid -- all of the extra warnings have to be enabled independently.
> Does it make sense to try to bring some structure to this area? Or maybe we
> say "no" and leave it to IDEs to impose that structure. Actually, I've
> already argued myself into that latter camp.
>
> In any case, I vote to accept this proposal.
>
> Richard
>
> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
>
> The proposal makes sense to me. I don't have a strong opinion, but I'm
> leaning towards acceptance.
>
> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
>
>> Dear Committee,
>>
>> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1]
>> that would flag occurrences of partial record selectors, e.g. the field `x`
>> in
>>
>> ```
>> data T = T1 { x :: Int, y :: Bool }
>>        | T2 { y :: Bool }
>> ```
>>
>> The proposal is well-specified, will never warn about total selectors
>> (e.g. `y` above), and allows for a smarter compiler to suppress warnings in
>> cases where a partial selector is used in a total context (e.g. `x (T1 42
>> True)`).
>>
>> I recommend acceptance.
>>
>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
>>
>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
>> > Dear Committee,
>> >
>> > Introduce `-Wincomplete-record-selectors`
>> > have been submitted by Adam Gundry
>> >
>> > https://github.com/ghc-proposals/ghc-proposals/pull/516
>> >
>> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
>> >
>> > I suggest that Eric shepherds this proposal.
>> >
>> > Please guide us to a conclusion as outlined in
>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> > Thanks,
>> > 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
>
>
> _______________________________________________
> 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/20220907/86361030/attachment.html>

From mail at joachim-breitner.de  Wed Sep  7 22:36:54 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 08 Sep 2022 00:36:54 +0200
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <CAJKmMz9HhA8pxQQJT=7XnX2oRxksz7CfqEfWz8-RFq+7SKR6og@mail.gmail.com>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
 <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
 <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>
 <010f0183180e85e5-b389b051-5efc-436e-9866-736b13a829b1-000000@us-east-2.amazonses.com>
 <CAJKmMz9HhA8pxQQJT=7XnX2oRxksz7CfqEfWz8-RFq+7SKR6og@mail.gmail.com>
Message-ID: <d9a96b611e66680f4cf3667b56635a7f1200e56a.camel@joachim-breitner.de>

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


From lists at richarde.dev  Thu Sep  8 12:38:29 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 8 Sep 2022 12:38:29 +0000
Subject: [ghc-steering-committee] Proposal #270: Support pun-free code.
 Recommendation: accept
In-Reply-To: <d9a96b611e66680f4cf3667b56635a7f1200e56a.camel@joachim-breitner.de>
References: <EC784B17-9831-4ECC-A93E-571E4D7D07CF@chrisdornan.com>
 <a3c57a2bd93b547e852382b723947e808b74afb6.camel@joachim-breitner.de>
 <DC86CC02-92C0-42DD-9E56-68130B2FD8F7@chrisdornan.com>
 <010f0182ff1fa2c1-eb9800f7-0d0e-4fd9-8b84-76880841cb48-000000@us-east-2.amazonses.com>
 <648DFB23-64B1-4A5E-B03B-11F794D85CFA@chrisdornan.com>
 <CAJKmMz9uEhguBu-OU1f8EfwR9AFrBVPUbMAwfVGaQEiuBw=EMg@mail.gmail.com>
 <0FD100C6-3A37-4DAE-88BF-794A67C64FBD@chrisdornan.com>
 <CAJKmMz97z03TXVpJORt=qVdh-E7HgadtrWQoCc6-qTqBH8QQGA@mail.gmail.com>
 <CAH6fHQmz-=33s0KzSk3+65UZ3V7onR0VRvOG0mu+5H2-BJDMOQ@mail.gmail.com>
 <098F6770-D175-4CAF-ACC5-8D49FF8A7398@chrisdornan.com>
 <010f0183180e85e5-b389b051-5efc-436e-9866-736b13a829b1-000000@us-east-2.amazonses.com>
 <CAJKmMz9HhA8pxQQJT=7XnX2oRxksz7CfqEfWz8-RFq+7SKR6og@mail.gmail.com>
 <d9a96b611e66680f4cf3667b56635a7f1200e56a.camel@joachim-breitner.de>
Message-ID: <010f01831d1bdf15-4d131071-d8ac-4c5a-b696-efb08a53ce8a-000000@us-east-2.amazonses.com>

Yes, I've been thinking about n+k-patterns, too. And datatype contexts! As in: are removal of these features about style? or something else? It's hard to say. So perhaps I walk back my "utterly agnostic about style" comment. (Indeed, the language itself cares deeply about something which most languages consider just style: indentation.)

I don't know how to balance these different aspects of our work, or how to keep everyone (or most) happy while being transparent and honest.

I mean, I personally think punning is bad style, which is why I support this proposal. But I also think that using snake_case for internal identifiers and camelCase for exported ones is a brilliant convention. Does that mean I want a warning when someone fails to do this? No. (Actually, that warning would be absolutely lovely. But I don't think it would have nearly enough support to make it a good idea.)

So maybe we return to saying more verifiable statements: We commit to supporting punning code into perpetuity, and so authors who want to continue to pun are welcome to do so. I'm quite happy committing to that.

Richard

> On Sep 7, 2022, at 6:36 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> 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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20220908/8dc484d0/attachment-0001.html>

From simon.peytonjones at gmail.com  Sun Sep 11 21:30:38 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sun, 11 Sep 2022 22:30:38 +0100
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
Message-ID: <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>

Eric

Would it be possible to conclude this discussion now?  And (I earnestly
hope) accept the proposal?  I don't think it's controversial, and it barely
needs a proposal anyway (since it's mainly about GHC internals).

I thought I'd start work on implementing it, in case that threw up any
issues.  I got drawn in, and have not invested about two person weeks in
the MR.  So I'm keen to get this done.  Thanks!

Simon

On Wed, 13 Jul 2022 at 01:51, Eric Seidel <eric at seidel.io> wrote:

> Hi all,
>
> Richard and Simon PJ have proposed tightening up the distinction between
> Type and Constraint in the type system. This proposal is primarily
> motivated by eliminating a long-standing class of compiler bugs, but it
> introduces a number of new (user-facing) types at the core of GHC's type
> system. And it does bring with it some additional capabilities like unboxed
> and unlifted implicit parameters, and a greater ability to abstract over
> arrows.
>
> I recommend acceptance of the proposal, but there is one question that I
> would like the broader committee to engage on.
>
> Simon and Richard have proposed introducing another arrow type as part of
> this proposal.
>
> type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep).
>               CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint
>
> I am a bit wary of introducing this arrow as a stable API at this point.
> It does not seem strictly necessary to make this part of the public API to
> implement this proposal, but doing so would commit us to a particular point
> in the design space. I've started a thread to discuss this on GitHub,
> please take a look and chime in if you have thoughts.
>
>
> https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818
>
> Thanks!
> Eric
>
> On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:
> > Dear Committee,
> >
> > The Type vs Constraint proposal
> > has been submitted by Richard Eisenberg and Simon Peyton Jones
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/518
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst
> >
> > I suggest that Eric shepherds this proposal.
> >
> > Please guide us to a conclusion as outlined in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> > Thanks,
> > 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/20220911/1d741035/attachment.html>

From arnaud.spiwack at tweag.io  Mon Sep 12 07:01:12 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 12 Sep 2022 09:01:12 +0200
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
Message-ID: <CAH6fHQk6CGEW0Wmf7O9kXmzarfqbgv3j3bG8999m7LsctAvpuQ@mail.gmail.com>

I've already spoken in favour of acceptance. But I should say that the
objections that I had do not hold in the current iteration of the proposal.
So I'm wholeheartedly in favour of acceptance. (In fact, this proposal is
barely a user-facing change, I don't think that there is any obstacle to
accepting the proposal within the week).

On Sun, Sep 11, 2022 at 11:30 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Eric
>
> Would it be possible to conclude this discussion now?  And (I earnestly
> hope) accept the proposal?  I don't think it's controversial, and it barely
> needs a proposal anyway (since it's mainly about GHC internals).
>
> I thought I'd start work on implementing it, in case that threw up any
> issues.  I got drawn in, and have not invested about two person weeks in
> the MR.  So I'm keen to get this done.  Thanks!
>
> Simon
>
> On Wed, 13 Jul 2022 at 01:51, Eric Seidel <eric at seidel.io> wrote:
>
>> Hi all,
>>
>> Richard and Simon PJ have proposed tightening up the distinction between
>> Type and Constraint in the type system. This proposal is primarily
>> motivated by eliminating a long-standing class of compiler bugs, but it
>> introduces a number of new (user-facing) types at the core of GHC's type
>> system. And it does bring with it some additional capabilities like unboxed
>> and unlifted implicit parameters, and a greater ability to abstract over
>> arrows.
>>
>> I recommend acceptance of the proposal, but there is one question that I
>> would like the broader committee to engage on.
>>
>> Simon and Richard have proposed introducing another arrow type as part of
>> this proposal.
>>
>> type (==>) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep).
>>               CONSTRAINT r1 -> CONSTRAINT r2 -> Constraint
>>
>> I am a bit wary of introducing this arrow as a stable API at this point.
>> It does not seem strictly necessary to make this part of the public API to
>> implement this proposal, but doing so would commit us to a particular point
>> in the design space. I've started a thread to discuss this on GitHub,
>> please take a look and chime in if you have thoughts.
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/518#discussion_r917416818
>>
>> Thanks!
>> Eric
>>
>> On Wed, Jul 6, 2022, at 08:10, Joachim Breitner wrote:
>> > Dear Committee,
>> >
>> > The Type vs Constraint proposal
>> > has been submitted by Richard Eisenberg and Simon Peyton Jones
>> >
>> > https://github.com/ghc-proposals/ghc-proposals/pull/518
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/proposals/0000-type-vs-constraint.rst
>> >
>> > I suggest that Eric shepherds this proposal.
>> >
>> > Please guide us to a conclusion as outlined in
>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> > Thanks,
>> > 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/20220912/d71fde8a/attachment.html>

From eric at seidel.io  Mon Sep 12 13:05:06 2022
From: eric at seidel.io (Eric Seidel)
Date: Mon, 12 Sep 2022 09:05:06 -0400
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
Message-ID: <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>

On Sun, Sep 11, 2022, at 17:30, Simon Peyton Jones wrote:
> Would it be possible to conclude this discussion now?  And (I earnestly 
> hope) accept the proposal?  I don't think it's controversial, and it 
> barely needs a proposal anyway (since it's mainly about GHC internals).

Yes, sorry. I believe we have consensus on the proposed changes themselves, but were stalled on the question of how to cleanly define the public API boundaries of GHC-the-library. 

This proposal clearly specifies which types are public and which are internal, and we have two related proposals exploring the question of how to specify public API boundaries:

* https://github.com/ghc-proposals/ghc-proposals/pull/524
* https://github.com/ghc-proposals/ghc-proposals/pull/528

My view remains that the exact mechanism of public/internal separation does not need to be fleshed out in order to accept this proposal. It can be hashed out in parallel with the implementation.

Richard, you were the main voice expressing concern about public API boundaries. Can we just merge this proposal and continue the public API discussion in #524 and #528?

From mail at joachim-breitner.de  Mon Sep 12 15:32:38 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 12 Sep 2022 17:32:38 +0200
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
 <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
Message-ID: <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>

Hi,

Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:
> My view remains that the exact mechanism of public/internal
> separation does not need to be fleshed out in order to accept this
> proposal. It can be hashed out in parallel with the implementation.

I agree with that – the concerns are nicely separated this way.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From eric at seidel.io  Sat Sep 17 15:30:13 2022
From: eric at seidel.io (Eric Seidel)
Date: Sat, 17 Sep 2022 11:30:13 -0400
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
Message-ID: <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>

Adam has updated the proposal to include the new -Wincomplete-record-selectors in -Wall (as it turns out -Wincomplete-record-updates was already included.

He also added a section providing a rationale for keeping the naming as-is, notably separate from -Wpartial-fields (which disallows the *definition* of partial record selectors).

https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming

I think this is a reasonable place to land, and recommend accepting the proposal in its current state.

Any objections?

On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
> I'd be happy to accept this one.
>
> In fact I'd prefer it if
>  * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
>  * But -wpartial-fields should definitely not be in -Wall because there 
> is absolutely nothing wrong with using named fields to help with 
> pattern matching and record construction -- places were partiality is 
> not an issue
> Simon
>
> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev> wrote:
>> I also lean toward acceptance.
>> 
>> However, I'm a little worried about the flourishing of warnings not in -Wall. Ignoring -Weverything -- which tends to be over the top, even for the paranoid -- all of the extra warnings have to be enabled independently. Does it make sense to try to bring some structure to this area? Or maybe we say "no" and leave it to IDEs to impose that structure. Actually, I've already argued myself into that latter camp.
>> 
>> In any case, I vote to accept this proposal.
>> 
>> Richard
>> 
>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>>> 
>>> The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance.
>>> 
>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
>>>> Dear Committee,
>>>> 
>>>> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in
>>>> 
>>>> ```
>>>> data T = T1 { x :: Int, y :: Bool }
>>>>        | T2 { y :: Bool }
>>>> ```
>>>> 
>>>> The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`).
>>>> 
>>>> I recommend acceptance.
>>>> 
>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
>>>> 
>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
>>>> > Dear Committee,
>>>> >
>>>> > Introduce `-Wincomplete-record-selectors`
>>>> > have been submitted by Adam Gundry
>>>> >
>>>> > https://github.com/ghc-proposals/ghc-proposals/pull/516
>>>> > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
>>>> >
>>>> > I suggest that Eric shepherds this proposal.
>>>> >
>>>> > Please guide us to a conclusion as outlined in 
>>>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> >
>>>> > Thanks,
>>>> > 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
>> 
>> _______________________________________________
>> 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

From eric at seidel.io  Sat Sep 17 15:33:46 2022
From: eric at seidel.io (Eric Seidel)
Date: Sat, 17 Sep 2022 11:33:46 -0400
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
 <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
 <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>
Message-ID: <ca2d7175-2c99-4178-8343-3779e2021adc@www.fastmail.com>

Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.

On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:
> Hi,
>
> Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:
>> My view remains that the exact mechanism of public/internal
>> separation does not need to be fleshed out in order to accept this
>> proposal. It can be hashed out in parallel with the implementation.
>
> I agree with that – the concerns are nicely separated this way.
>
> 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

From chris at chrisdornan.com  Sat Sep 17 17:50:49 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Sat, 17 Sep 2022 18:50:49 +0100
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
 <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
Message-ID: <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>

+1 to this: I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement.

> On 2022-09-17, at 16:30, Eric Seidel <eric at seidel.io> wrote:
> 
> Adam has updated the proposal to include the new -Wincomplete-record-selectors in -Wall (as it turns out -Wincomplete-record-updates was already included.
> 
> He also added a section providing a rationale for keeping the naming as-is, notably separate from -Wpartial-fields (which disallows the *definition* of partial record selectors).
> 
> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming
> 
> I think this is a reasonable place to land, and recommend accepting the proposal in its current state.
> 
> Any objections?
> 
> On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
>> I'd be happy to accept this one.
>> 
>> In fact I'd prefer it if
>> * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
>> * But -wpartial-fields should definitely not be in -Wall because there 
>> is absolutely nothing wrong with using named fields to help with 
>> pattern matching and record construction -- places were partiality is 
>> not an issue
>> Simon
>> 
>> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev> wrote:
>>> I also lean toward acceptance.
>>> 
>>> However, I'm a little worried about the flourishing of warnings not in -Wall. Ignoring -Weverything -- which tends to be over the top, even for the paranoid -- all of the extra warnings have to be enabled independently. Does it make sense to try to bring some structure to this area? Or maybe we say "no" and leave it to IDEs to impose that structure. Actually, I've already argued myself into that latter camp.
>>> 
>>> In any case, I vote to accept this proposal.
>>> 
>>> Richard
>>> 
>>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>>>> 
>>>> The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance.
>>>> 
>>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
>>>>> Dear Committee,
>>>>> 
>>>>> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in
>>>>> 
>>>>> ```
>>>>> data T = T1 { x :: Int, y :: Bool }
>>>>>       | T2 { y :: Bool }
>>>>> ```
>>>>> 
>>>>> The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`).
>>>>> 
>>>>> I recommend acceptance.
>>>>> 
>>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
>>>>> 
>>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
>>>>>> Dear Committee,
>>>>>> 
>>>>>> Introduce `-Wincomplete-record-selectors`
>>>>>> have been submitted by Adam Gundry
>>>>>> 
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/516
>>>>>> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
>>>>>> 
>>>>>> I suggest that Eric shepherds this proposal.
>>>>>> 
>>>>>> Please guide us to a conclusion as outlined in 
>>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>>>> 
>>>>>> Thanks,
>>>>>> 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
>>> 
>>> _______________________________________________
>>> 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


From simon.peytonjones at gmail.com  Mon Sep 19 08:38:55 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 19 Sep 2022 09:38:55 +0100
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
 <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
 <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>
Message-ID: <CAJKmMz_UAdm6Q6PqLSTV325rEQDeU1Vw3tdH3sPUd-Bf3w6GLA@mail.gmail.com>

I'm happy to accept this proposal too.

I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement
>

What is "Simon's refinement".  I think you are referring to :
-
>
> I'd prefer if -wpartial-record-selectors and -wpartial-record-updates were
> in -Wall

- but in fact that's what the proposal says, I believe.
-
- Simon

On Sat, 17 Sept 2022 at 18:51, Chris Dornan <chris at chrisdornan.com> wrote:

> +1 to this: I’m  happy with Adam’s tweaked proposal, or better with
> Simon’s refinement.
>
> > On 2022-09-17, at 16:30, Eric Seidel <eric at seidel.io> wrote:
> >
> > Adam has updated the proposal to include the new
> -Wincomplete-record-selectors in -Wall (as it turns out
> -Wincomplete-record-updates was already included.
> >
> > He also added a section providing a rationale for keeping the naming
> as-is, notably separate from -Wpartial-fields (which disallows the
> *definition* of partial record selectors).
> >
> >
> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming
> >
> > I think this is a reasonable place to land, and recommend accepting the
> proposal in its current state.
> >
> > Any objections?
> >
> > On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
> >> I'd be happy to accept this one.
> >>
> >> In fact I'd prefer it if
> >> * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
> >> * But -wpartial-fields should definitely not be in -Wall because there
> >> is absolutely nothing wrong with using named fields to help with
> >> pattern matching and record construction -- places were partiality is
> >> not an issue
> >> Simon
> >>
> >> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev>
> wrote:
> >>> I also lean toward acceptance.
> >>>
> >>> However, I'm a little worried about the flourishing of warnings not in
> -Wall. Ignoring -Weverything -- which tends to be over the top, even for
> the paranoid -- all of the extra warnings have to be enabled independently.
> Does it make sense to try to bring some structure to this area? Or maybe we
> say "no" and leave it to IDEs to impose that structure. Actually, I've
> already argued myself into that latter camp.
> >>>
> >>> In any case, I vote to accept this proposal.
> >>>
> >>> Richard
> >>>
> >>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
> wrote:
> >>>>
> >>>> The proposal makes sense to me. I don't have a strong opinion, but
> I'm leaning towards acceptance.
> >>>>
> >>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
> >>>>> Dear Committee,
> >>>>>
> >>>>> Adam Gundry has proposed a new warning
> -Wincomplete-record-selectors[1] that would flag occurrences of partial
> record selectors, e.g. the field `x` in
> >>>>>
> >>>>> ```
> >>>>> data T = T1 { x :: Int, y :: Bool }
> >>>>>       | T2 { y :: Bool }
> >>>>> ```
> >>>>>
> >>>>> The proposal is well-specified, will never warn about total
> selectors (e.g. `y` above), and allows for a smarter compiler to suppress
> warnings in cases where a partial selector is used in a total context (e.g.
> `x (T1 42 True)`).
> >>>>>
> >>>>> I recommend acceptance.
> >>>>>
> >>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>>
> >>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
> >>>>>> Dear Committee,
> >>>>>>
> >>>>>> Introduce `-Wincomplete-record-selectors`
> >>>>>> have been submitted by Adam Gundry
> >>>>>>
> >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>>>
> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
> >>>>>>
> >>>>>> I suggest that Eric shepherds this proposal.
> >>>>>>
> >>>>>> Please guide us to a conclusion as outlined in
> >>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>>>>>
> >>>>>> Thanks,
> >>>>>> 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
> >>>
> >>> _______________________________________________
> >>> 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
>
> _______________________________________________
> 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/20220919/c941c7dc/attachment.html>

From chris at chrisdornan.com  Mon Sep 19 10:51:19 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 19 Sep 2022 11:51:19 +0100
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <CAJKmMz_UAdm6Q6PqLSTV325rEQDeU1Vw3tdH3sPUd-Bf3w6GLA@mail.gmail.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
 <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
 <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>
 <CAJKmMz_UAdm6Q6PqLSTV325rEQDeU1Vw3tdH3sPUd-Bf3w6GLA@mail.gmail.com>
Message-ID: <C6308354-EB18-4862-9EE6-7FE6B80F5174@chrisdornan.com>

I am sorry for the confusion — I misread the thread. Correction: +1 for the above amended proposal with -Wall so strengthened. That is all.

> On 2022-09-19, at 09:38, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I'm happy to accept this proposal too.
> 
> I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement
> 
> What is "Simon's refinement".  I think you are referring to :
> • I'd prefer if -wpartial-record-selectors and -wpartial-record-updates were in -Wall
> • but in fact that's what the proposal says, I believe.
> 
> • Simon 
> 
> On Sat, 17 Sept 2022 at 18:51, Chris Dornan <chris at chrisdornan.com> wrote:
> +1 to this: I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement.
> 
> > On 2022-09-17, at 16:30, Eric Seidel <eric at seidel.io> wrote:
> > 
> > Adam has updated the proposal to include the new -Wincomplete-record-selectors in -Wall (as it turns out -Wincomplete-record-updates was already included.
> > 
> > He also added a section providing a rationale for keeping the naming as-is, notably separate from -Wpartial-fields (which disallows the *definition* of partial record selectors).
> > 
> > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming
> > 
> > I think this is a reasonable place to land, and recommend accepting the proposal in its current state.
> > 
> > Any objections?
> > 
> > On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
> >> I'd be happy to accept this one.
> >> 
> >> In fact I'd prefer it if
> >> * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
> >> * But -wpartial-fields should definitely not be in -Wall because there 
> >> is absolutely nothing wrong with using named fields to help with 
> >> pattern matching and record construction -- places were partiality is 
> >> not an issue
> >> Simon
> >> 
> >> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev> wrote:
> >>> I also lean toward acceptance.
> >>> 
> >>> However, I'm a little worried about the flourishing of warnings not in -Wall. Ignoring -Weverything -- which tends to be over the top, even for the paranoid -- all of the extra warnings have to be enabled independently. Does it make sense to try to bring some structure to this area? Or maybe we say "no" and leave it to IDEs to impose that structure. Actually, I've already argued myself into that latter camp.
> >>> 
> >>> In any case, I vote to accept this proposal.
> >>> 
> >>> Richard
> >>> 
> >>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> >>>> 
> >>>> The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance.
> >>>> 
> >>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
> >>>>> Dear Committee,
> >>>>> 
> >>>>> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in
> >>>>> 
> >>>>> ```
> >>>>> data T = T1 { x :: Int, y :: Bool }
> >>>>>       | T2 { y :: Bool }
> >>>>> ```
> >>>>> 
> >>>>> The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`).
> >>>>> 
> >>>>> I recommend acceptance.
> >>>>> 
> >>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>> 
> >>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
> >>>>>> Dear Committee,
> >>>>>> 
> >>>>>> Introduce `-Wincomplete-record-selectors`
> >>>>>> have been submitted by Adam Gundry
> >>>>>> 
> >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/516
> >>>>>> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
> >>>>>> 
> >>>>>> I suggest that Eric shepherds this proposal.
> >>>>>> 
> >>>>>> Please guide us to a conclusion as outlined in 
> >>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
> >>>>>> 
> >>>>>> Thanks,
> >>>>>> 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
> >>> 
> >>> _______________________________________________
> >>> 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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Mon Sep 19 17:42:17 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Sep 2022 19:42:17 +0200
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
Message-ID: <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>

Hi,

also in light of the discussion at Haskell Symposium, can we proceed
with this (or drop this)? Arnaud was most vocally in the “against”
camp; are you still against it?

NB: Opening PRs and discussing them with the general public is welcome
even before implementors have been found, and committee members can of
course join that discussion. Only the formal committee submission would
be blocked until implementors have been found.

Cheers,
Joachim

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From arnaud.spiwack at tweag.io  Tue Sep 20 13:09:18 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 20 Sep 2022 15:09:18 +0200
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
 <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
Message-ID: <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>

I haven't been convinced yet. As I said in my previous email, I'm a priori
against this proposal. But this is a gut feeling. More importantly than
that, I don't feel that we have documented how other communities handle
this. I also don't feel that the number of unimplemented proposals is so
high as to be a problem.

On Mon, Sep 19, 2022 at 7:42 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> also in light of the discussion at Haskell Symposium, can we proceed
> with this (or drop this)? Arnaud was most vocally in the “against”
> camp; are you still against it?
>
> NB: Opening PRs and discussing them with the general public is welcome
> even before implementors have been found, and committee members can of
> course join that discussion. Only the formal committee submission would
> be blocked until implementors have been found.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220920/d4bc601f/attachment.html>

From mail at joachim-breitner.de  Tue Sep 20 13:43:39 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 20 Sep 2022 15:43:39 +0200
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
 <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
 <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>
Message-ID: <57641e5d2c3e4f5f061579665713faa1120341f1.camel@joachim-breitner.de>

Hello,

while I think the problem exists and would welcome a process
refinement, it certainly isn’t so big to spend too much of our own
attention on it (which is the precise resource I was trying to save).
And it certainly isn’t pressing enough to hold a vote when there isn’t
consensus.

So given that we don’t have a consensus, I suggest to not spend more
time on it, let’s reject it (and remember where it is to be revived, if
and when the problem becomes more clearer visible).

Cheers,
Joachim
(with no pride dented, no worries)

Am Dienstag, dem 20.09.2022 um 15:09 +0200 schrieb Spiwack, Arnaud:
> I haven't been convinced yet. As I said in my previous email, I'm a
> priori against this proposal. But this is a gut feeling. More
> importantly than that, I don't feel that we have documented how other
> communities handle this. I also don't feel that the number of
> unimplemented proposals is so high as to be a problem.
> 
> On Mon, Sep 19, 2022 at 7:42 PM Joachim Breitner
> <mail at joachim-breitner.de> wrote:
> > Hi,
> > 
> > also in light of the discussion at Haskell Symposium, can we
> > proceed
> > with this (or drop this)? Arnaud was most vocally in the “against”
> > camp; are you still against it?
> > 
> > NB: Opening PRs and discussing them with the general public is
> > welcome
> > even before implementors have been found, and committee members can
> > of
> > course join that discussion. Only the formal committee submission
> > would
> > be blocked until implementors have been found.
> > 
> > Cheers,
> > Joachim
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From simon.peytonjones at gmail.com  Mon Sep 26 09:26:28 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 26 Sep 2022 10:26:28 +0100
Subject: [ghc-steering-committee] Baldur stepping down
Message-ID: <CAJKmMz_L3QsxG+yUn+cc=ER8N5v===uNDwvpOT7MzY+OKPP39A@mail.gmail.com>

Friends

I'm writing to let you know that Baldur (icelandjack) has decided to step
down from the GHC Steering Committee.

He is incredibly talented, but the commitments of his job and a newborn
daughter (congratulations Baldur) have made it hard for him to keep up with
GHC proposals.

Thank you Baldur.  You have given a lot to Haskell already (notably
deriving via) and I'm sure there is lots more to come.

best wishes

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220926/71186d05/attachment.html>

From rae at richarde.dev  Tue Sep 27 20:42:14 2022
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 27 Sep 2022 20:42:14 +0000
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <ca2d7175-2c99-4178-8343-3779e2021adc@www.fastmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
 <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
 <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>
 <ca2d7175-2c99-4178-8343-3779e2021adc@www.fastmail.com>
Message-ID: <010f018380af97e2-edb5d5b7-d9e3-4a96-90a9-f126913f01d4-000000@us-east-2.amazonses.com>

Yes, I'm fine here -- would still love to have this worked out, but I don't want to hold things up further.

Richard

> On Sep 17, 2022, at 11:33 AM, Eric Seidel <eric at seidel.io> wrote:
> 
> Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.
> 
> On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:
>> Hi,
>> 
>> Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:
>>> My view remains that the exact mechanism of public/internal
>>> separation does not need to be fleshed out in order to accept this
>>> proposal. It can be hashed out in parallel with the implementation.
>> 
>> I agree with that – the concerns are nicely separated this way.
>> 
>> 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


From eric at seidel.io  Wed Sep 28 01:10:30 2022
From: eric at seidel.io (Eric Seidel)
Date: Tue, 27 Sep 2022 21:10:30 -0400
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <010f018380af97e2-edb5d5b7-d9e3-4a96-90a9-f126913f01d4-000000@us-east-2.amazonses.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
 <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
 <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>
 <ca2d7175-2c99-4178-8343-3779e2021adc@www.fastmail.com>
 <010f018380af97e2-edb5d5b7-d9e3-4a96-90a9-f126913f01d4-000000@us-east-2.amazonses.com>
Message-ID: <48affc16-3726-4e97-b23e-c93f4521f5ec@app.fastmail.com>

Thanks Richard!

Joachim, I think we're good to merge now!

On Tue, Sep 27, 2022, at 16:42, Richard Eisenberg wrote:
> Yes, I'm fine here -- would still love to have this worked out, but I 
> don't want to hold things up further.
>
> Richard
>
>> On Sep 17, 2022, at 11:33 AM, Eric Seidel <eric at seidel.io> wrote:
>> 
>> Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.
>> 
>> On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:
>>> Hi,
>>> 
>>> Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:
>>>> My view remains that the exact mechanism of public/internal
>>>> separation does not need to be fleshed out in order to accept this
>>>> proposal. It can be hashed out in parallel with the implementation.
>>> 
>>> I agree with that – the concerns are nicely separated this way.
>>> 
>>> 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

From eric at seidel.io  Wed Sep 28 01:13:17 2022
From: eric at seidel.io (Eric Seidel)
Date: Tue, 27 Sep 2022 21:13:17 -0400
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <C6308354-EB18-4862-9EE6-7FE6B80F5174@chrisdornan.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
 <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
 <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>
 <CAJKmMz_UAdm6Q6PqLSTV325rEQDeU1Vw3tdH3sPUd-Bf3w6GLA@mail.gmail.com>
 <C6308354-EB18-4862-9EE6-7FE6B80F5174@chrisdornan.com>
Message-ID: <979347a9-ba4b-4e6d-b3cf-057b80148f12@app.fastmail.com>

The feedback from the committee has been unanimously in favor, especially with the refinement to strengthen -Wall.

Joachim, I think we're good to merge.

On Mon, Sep 19, 2022, at 06:51, Chris Dornan wrote:
> I am sorry for the confusion — I misread the thread. Correction: +1 for 
> the above amended proposal with -Wall so strengthened. That is all.
>
>> On 2022-09-19, at 09:38, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> 
>> I'm happy to accept this proposal too.
>> 
>> I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement
>> 
>> What is "Simon's refinement".  I think you are referring to :
>> • I'd prefer if -wpartial-record-selectors and -wpartial-record-updates were in -Wall
>> • but in fact that's what the proposal says, I believe.
>> 
>> • Simon 
>> 
>> On Sat, 17 Sept 2022 at 18:51, Chris Dornan <chris at chrisdornan.com> wrote:
>> +1 to this: I’m  happy with Adam’s tweaked proposal, or better with Simon’s refinement.
>> 
>> > On 2022-09-17, at 16:30, Eric Seidel <eric at seidel.io> wrote:
>> > 
>> > Adam has updated the proposal to include the new -Wincomplete-record-selectors in -Wall (as it turns out -Wincomplete-record-updates was already included.
>> > 
>> > He also added a section providing a rationale for keeping the naming as-is, notably separate from -Wpartial-fields (which disallows the *definition* of partial record selectors).
>> > 
>> > https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst#naming
>> > 
>> > I think this is a reasonable place to land, and recommend accepting the proposal in its current state.
>> > 
>> > Any objections?
>> > 
>> > On Wed, Sep 7, 2022, at 18:05, Simon Peyton Jones wrote:
>> >> I'd be happy to accept this one.
>> >> 
>> >> In fact I'd prefer it if
>> >> * -wpartial-record-selectors and -wpartial-record-updates were in -Wall
>> >> * But -wpartial-fields should definitely not be in -Wall because there 
>> >> is absolutely nothing wrong with using named fields to help with 
>> >> pattern matching and record construction -- places were partiality is 
>> >> not an issue
>> >> Simon
>> >> 
>> >> On Wed, 7 Sept 2022 at 12:35, Richard Eisenberg <lists at richarde.dev> wrote:
>> >>> I also lean toward acceptance.
>> >>> 
>> >>> However, I'm a little worried about the flourishing of warnings not in -Wall. Ignoring -Weverything -- which tends to be over the top, even for the paranoid -- all of the extra warnings have to be enabled independently. Does it make sense to try to bring some structure to this area? Or maybe we say "no" and leave it to IDEs to impose that structure. Actually, I've already argued myself into that latter camp.
>> >>> 
>> >>> In any case, I vote to accept this proposal.
>> >>> 
>> >>> Richard
>> >>> 
>> >>>> On Aug 24, 2022, at 1:47 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>> >>>> 
>> >>>> The proposal makes sense to me. I don't have a strong opinion, but I'm leaning towards acceptance.
>> >>>> 
>> >>>> On Tue, Aug 23, 2022 at 8:14 PM Eric Seidel <eric at seidel.io> wrote:
>> >>>>> Dear Committee,
>> >>>>> 
>> >>>>> Adam Gundry has proposed a new warning -Wincomplete-record-selectors[1] that would flag occurrences of partial record selectors, e.g. the field `x` in
>> >>>>> 
>> >>>>> ```
>> >>>>> data T = T1 { x :: Int, y :: Bool }
>> >>>>>       | T2 { y :: Bool }
>> >>>>> ```
>> >>>>> 
>> >>>>> The proposal is well-specified, will never warn about total selectors (e.g. `y` above), and allows for a smarter compiler to suppress warnings in cases where a partial selector is used in a total context (e.g. `x (T1 42 True)`).
>> >>>>> 
>> >>>>> I recommend acceptance.
>> >>>>> 
>> >>>>> [1]: https://github.com/ghc-proposals/ghc-proposals/pull/516
>> >>>>> 
>> >>>>> On Sun, Aug 14, 2022, at 13:01, Joachim Breitner wrote:
>> >>>>>> Dear Committee,
>> >>>>>> 
>> >>>>>> Introduce `-Wincomplete-record-selectors`
>> >>>>>> have been submitted by Adam Gundry
>> >>>>>> 
>> >>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/516
>> >>>>>> https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selectors/proposals/0000-incomplete-record-selectors.rst
>> >>>>>> 
>> >>>>>> I suggest that Eric shepherds this proposal.
>> >>>>>> 
>> >>>>>> Please guide us to a conclusion as outlined in 
>> >>>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >>>>>> 
>> >>>>>> Thanks,
>> >>>>>> 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
>> >>> 
>> >>> _______________________________________________
>> >>> 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
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee