From simon.peytonjones at gmail.com  Fri Sep  1 09:37:06 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 1 Sep 2023 10:37:06 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
Message-ID: <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>

Dear Simon, Vlad, Eric, Chris, Moritz

I would love to hear from you about this proposal.  *Please*.

I plan to accept it unless I hear dissent.  But I would much rather have an
explicit response from you than take silence as assent.  You are a member
of the committee, after all!

My apologies if I have missed your reply

Simon

On Thu, 24 Aug 2023 at 16:42, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC steering committee
>
> A month ago I wrote to you concerning GHC Proposal 601 about GHC
> extensions
> <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
> .
>
> We propose a categorization scheme for Haskell language extensions. This
>> scheme is simple, in that there are few categories that are described in
>> terms of the user-relevant aspects, and it is actionable, in that it
>> suggests concrete changes to the warning system of GHC that allow users to
>> express their own risk tolerance and get guidance as they upgrade their
>> compiler
>>
>
> It's holiday time I know, but still, I did not get a single reply.  Is
> that because you all love it or you all hate it?  RSVP!
>
> I propose acceptance, modulo a few clarifications which I have posted on
> the discussion thread.
>
> Please reply, yea or nay.
>
> Simon
>
> On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC Steering Committee
>>
>> Proposal #601
>> <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>
>> says
>>
>> We propose a categorization scheme for Haskell language extensions. This
>> scheme is simple, in that there are few categories that are described in
>> terms of the user-relevant aspects, and it is actionable, in that it
>> suggests concrete changes to the warning system of GHC that allow users to
>> express their own risk tolerance and get guidance as they upgrade their
>> compiler
>>
>> I'm happy with this proposal: it seems simple, comprehensible, and
>> actionable.
>>
>> The only question in my mind is whether it is worth the bother.  I'd love
>> to hear from the practitioners on the committee.
>>
>> But I propose that we accept it.
>>
>> Simon
>>
>>
>> On Mon, 24 Jul 2023 at 14:39, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Dear Committee,
>>>
>>> David Thrane Christiansen suggested to categorize extensions into
>>> Experimental, Mature, Deprecated and Legacy, and add warning flag to
>>> GHC that allow users to be warned about (or shouted at for) using such
>>> extensions, if they choose so.
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/601
>>>
>>> https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md
>>>
>>> Because of the meta-like aspect of this proposal, I’d like to assign
>>> this to Simon PJ.
>>>
>>>
>>> Please guide us to a conclusion as outlined in
>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>
>>>
>>> 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/20230901/83147e62/attachment.html>

From chris at chrisdornan.com  Fri Sep  1 10:56:09 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 1 Sep 2023 11:56:09 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
Message-ID: <0055DB1D-153E-4D6A-B302-CE3DEDAF4E67@chrisdornan.com>

I am sorry Simon,

Because I was so heavily involved in its preparation I assumed my support for the proposal was a given.

I enthusiastically support this proposal. I cannot overemphasise how import I think it is that

  1) we as a committee clarify for ourselves the status of these extensions and

  2) how useful I think it is for developers to have ready access such a definitive taxonomy.

Of course it doesn't solve all of our problems, but let's build on it and the feedback we get from the community.

Chris

> On 1 Sep 2023, at 10:37, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Dear Simon, Vlad, Eric, Chris, Moritz
> 
> I would love to hear from you about this proposal.  Please. 
> 
> I plan to accept it unless I hear dissent.  But I would much rather have an explicit response from you than take silence as assent.  You are a member of the committee, after all!
> 
> My apologies if I have missed your reply
> 
> Simon
> 
> On Thu, 24 Aug 2023 at 16:42, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> Dear GHC steering committee
>> 
>> A month ago I wrote to you concerning GHC Proposal 601 about GHC extensions <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md>.
>> 
>>> We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler
>> 
>> It's holiday time I know, but still, I did not get a single reply.  Is that because you all love it or you all hate it?  RSVP!
>> 
>> I propose acceptance, modulo a few clarifications which I have posted on the discussion thread.
>> 
>> Please reply, yea or nay.
>> 
>> Simon
>> 
>> On Tue, 25 Jul 2023 at 15:58, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> Dear GHC Steering Committee
>>> 
>>> Proposal #601 <https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md> says 
>>> 
>>> We propose a categorization scheme for Haskell language extensions. This scheme is simple, in that there are few categories that are described in terms of the user-relevant aspects, and it is actionable, in that it suggests concrete changes to the warning system of GHC that allow users to express their own risk tolerance and get guidance as they upgrade their compiler 
>>> 
>>> I'm happy with this proposal: it seems simple, comprehensible, and actionable.  
>>> 
>>> The only question in my mind is whether it is worth the bother.  I'd love to hear from the practitioners on the committee.
>>> 
>>> But I propose that we accept it.
>>> 
>>> Simon
>>> 
>>> 
>>> On Mon, 24 Jul 2023 at 14:39, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>>> Dear Committee,
>>>> 
>>>> David Thrane Christiansen suggested to categorize extensions into
>>>> Experimental, Mature, Deprecated and Legacy, and add warning flag to
>>>> GHC that allow users to be warned about (or shouted at for) using such
>>>> extensions, if they choose so.
>>>> 
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/601
>>>> https://github.com/david-christiansen/ghc-proposals/blob/extension-lifecycle-proposal/proposals/0000-extension-lifecycle-framework.md
>>>> 
>>>> Because of the meta-like aspect of this proposal, I’d like to assign
>>>> this to Simon PJ.
>>>> 
>>>> 
>>>> Please guide us to a conclusion as outlined in 
>>>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>>> 
>>>> 
>>>> Cheers,
>>>> Joachim
>>>> 
>>>> 
>>>> -- 
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de <mailto:mail at 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

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

From vlad.z.4096 at gmail.com  Fri Sep  1 12:18:41 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Fri, 1 Sep 2023 14:18:41 +0200
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
Message-ID: <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>

I agree that we need a categorisation of extension language flags, but I'm
not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set
of labels. In fact, I wouldn't want to commit to any particular
categorisation before we actually go through all the extensions in GHC and
see for ourselves that they can be adequately categorized according to the
proposed system.

The proposal says "classifications of individual language extensions will
be left to a future proposal". Well, I am skeptical that this separation
makes sense. I would much prefer if we were discussing a concrete
categorisation proposal, not just a set of four labels whose implications I
can't fully grasp.

Vlad

On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear Simon, Vlad, Eric, Chris, Moritz
>
> I would love to hear from you about this proposal.  *Please*.
>
> I plan to accept it unless I hear dissent.  But I would much rather have
> an explicit response from you than take silence as assent.  You are a
> member of the committee, after all!
>
> My apologies if I have missed your reply
>
> Simon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230901/5fcb63ad/attachment.html>

From marlowsd at gmail.com  Fri Sep  1 16:17:44 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 1 Sep 2023 17:17:44 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
Message-ID: <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>

A few things make this not a straightforward thumbs up for me, though I'm
not strongly against.

What is the interaction with GHC20xx? Presumably we want to say something
like GHC20xx will never include any Deprecated or Legacy extensions? What
about Unsable? if an extension transitions from Stable -> Legacy, would we
remove it from the next GHC20xx?

Something doesn't feel quite right about the warning system. If a module
can start with

{-# OPTIONS_GHC -Wno-XDeprecated #-}
{-# LANGUAGE OverlappingInstances #-}

and silently use an extension that the {build system, user, project} wanted
to disallow, have we achieved anything? Compare this to the current
situation, where the environment can say -XNoOverlappingInstances and code
can override that with {-# LANGUAGE OverlappingInstances #-} - there's
essentially no difference, we just added another layer of disable/override
that isn't buying us anything.

(note I'm viewing this through the spectacles of -Werror, because I've come
to believe that warnings are essentially not useful unless given teeth with
-Werror.)

Cheers
Simon

On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> I agree that we need a categorisation of extension language flags, but I'm
> not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set
> of labels. In fact, I wouldn't want to commit to any particular
> categorisation before we actually go through all the extensions in GHC and
> see for ourselves that they can be adequately categorized according to the
> proposed system.
>
> The proposal says "classifications of individual language extensions will
> be left to a future proposal". Well, I am skeptical that this separation
> makes sense. I would much prefer if we were discussing a concrete
> categorisation proposal, not just a set of four labels whose implications I
> can't fully grasp.
>
> Vlad
>
> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear Simon, Vlad, Eric, Chris, Moritz
>>
>> I would love to hear from you about this proposal.  *Please*.
>>
>> I plan to accept it unless I hear dissent.  But I would much rather have
>> an explicit response from you than take silence as assent.  You are a
>> member of the committee, after all!
>>
>> My apologies if I have missed your reply
>>
>> Simon
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230901/48cfec3b/attachment.html>

From marlowsd at gmail.com  Fri Sep  1 16:21:07 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 1 Sep 2023 17:21:07 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
Message-ID: <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>

On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com> wrote:

> A few things make this not a straightforward thumbs up for me, though I'm
> not strongly against.
>
> What is the interaction with GHC20xx? Presumably we want to say something
> like GHC20xx will never include any Deprecated or Legacy extensions? What
> about Unsable? if an extension transitions from Stable -> Legacy, would we
> remove it from the next GHC20xx?
>

Ah, I just noticed that the proposal does say something about this:

For existing, or future, language sets such as GHC2021 or Haskell98, it is
> expected that none of the contained extensions would be Unstable.
> However, this proposal does not seek to impose any particular policy on the
> inclusion of extensions into language sets - the developers and the
> steering committee are always in the best position to make a decision about
> a concrete extension and extension set.
>

OK.

Simon



> Something doesn't feel quite right about the warning system. If a module
> can start with
>
> {-# OPTIONS_GHC -Wno-XDeprecated #-}
> {-# LANGUAGE OverlappingInstances #-}
>
> and silently use an extension that the {build system, user, project}
> wanted to disallow, have we achieved anything? Compare this to the current
> situation, where the environment can say -XNoOverlappingInstances and code
> can override that with {-# LANGUAGE OverlappingInstances #-} - there's
> essentially no difference, we just added another layer of disable/override
> that isn't buying us anything.
>
> (note I'm viewing this through the spectacles of -Werror, because I've
> come to believe that warnings are essentially not useful unless given teeth
> with -Werror.)
>
> Cheers
> Simon
>
> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <vlad.z.4096 at gmail.com>
> wrote:
>
>> I agree that we need a categorisation of extension language flags, but
>> I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right
>> set of labels. In fact, I wouldn't want to commit to any particular
>> categorisation before we actually go through all the extensions in GHC and
>> see for ourselves that they can be adequately categorized according to the
>> proposed system.
>>
>> The proposal says "classifications of individual language extensions will
>> be left to a future proposal". Well, I am skeptical that this separation
>> makes sense. I would much prefer if we were discussing a concrete
>> categorisation proposal, not just a set of four labels whose implications I
>> can't fully grasp.
>>
>> Vlad
>>
>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>>
>>> I would love to hear from you about this proposal.  *Please*.
>>>
>>> I plan to accept it unless I hear dissent.  But I would much rather have
>>> an explicit response from you than take silence as assent.  You are a
>>> member of the committee, after all!
>>>
>>> My apologies if I have missed your reply
>>>
>>> Simon
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230901/5e4d364b/attachment.html>

From lists at richarde.dev  Fri Sep  1 16:56:55 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 1 Sep 2023 16:56:55 +0000
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
Message-ID: <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>

I've just posted on the GitHub ticket. I remain against the proposal in its current form, mostly because it means (if I understand correctly) that everyone who says `default-language: Haskell2010` will get warnings.

Richard

> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> A few things make this not a straightforward thumbs up for me, though I'm not strongly against.
> 
> What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?
> 
> Ah, I just noticed that the proposal does say something about this:
> 
> For existing, or future, language sets such as GHC2021 or Haskell98, it is expected that none of the contained extensions would be Unstable. However, this proposal does not seek to impose any particular policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set.
>  
> OK.
> 
> Simon
> 
> 
> 
> Something doesn't feel quite right about the warning system. If a module can start with
> 
> {-# OPTIONS_GHC -Wno-XDeprecated #-}
> {-# LANGUAGE OverlappingInstances #-}
> 
> and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything.
> 
> (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.)
> 
> Cheers
> Simon
> 
> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system.
> 
> The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.
> 
> Vlad
> 
> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> Dear Simon, Vlad, Eric, Chris, Moritz
> 
> I would love to hear from you about this proposal.  Please. 
> 
> I plan to accept it unless I hear dissent.  But I would much rather have an explicit response from you than take silence as assent.  You are a member of the committee, after all!
> 
> My apologies if I have missed your reply
> 
> Simon
> _______________________________________________
> 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/20230901/0044880d/attachment-0001.html>

From eric at seidel.io  Sat Sep  2 00:23:23 2023
From: eric at seidel.io (Eric Seidel)
Date: Fri, 01 Sep 2023 20:23:23 -0400
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
Message-ID: <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>

There's a non-normative and a normative component to this proposal.

The non-normative piece says that there should be a categorization scheme for language extensions. That is inarguable in my opinion. The proposal also suggests an initial framework of four categories, which seems like a reasonable place to start. (Vlad says we should first figure out how to map all extensions to the categories; I disagree. We can iterate on the categories over time, as needed.)

The normative piece of the proposal says that we should start warning on the use of any Deprecated, Unstable, or Legacy extensions. This seems like a reasonable ideal, but the practicality kind of hinges on the bucketing of specific extensions (and on Richard's question of how `default-language` is interpreted). The authors give some recommendations of how to bucket particular extensions, but it's not exhaustive and I also view it as the authors' desire rather than a specific commitment of the proposal.

So in my view:

* Yes, we should have a framework for categorizing the jungle of language extensions, and the proposal seems like a fine starting point.
* Yes, we should have a set of warnings for users who would like to forbid certain categories of extensions.
* We should probably defer any decisions about default enablement of warnings until we have a complete proposed categorization. And that discussion should include some analysis of the pervasiveness of "deprecated", "unstable", and "legacy" extensions so we can judge the amount of churn. Just like any other discussion about deprecation.

Eric

On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
> I've just posted on the GitHub ticket. I remain against the proposal in 
> its current form, mostly because it means (if I understand correctly) 
> that everyone who says `default-language: Haskell2010` will get 
> warnings.
>
> Richard
>
>> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com> wrote:
>>> A few things make this not a straightforward thumbs up for me, though I'm not strongly against.
>>> 
>>> What is the interaction with GHC20xx? Presumably we want to say something like GHC20xx will never include any Deprecated or Legacy extensions? What about Unsable? if an extension transitions from Stable -> Legacy, would we remove it from the next GHC20xx?
>> 
>> Ah, I just noticed that the proposal does say something about this:
>> 
>>> For existing, or future, language sets such as `GHC2021` or `Haskell98`, it is expected that none of the contained extensions would be `Unstable`. However, this proposal does not seek to impose any particular policy on the inclusion of extensions into language sets - the developers and the steering committee are always in the best position to make a decision about a concrete extension and extension set.
>>  
>> OK.
>> 
>> Simon
>> 
>> 
>>> 
>>> Something doesn't feel quite right about the warning system. If a module can start with
>>> 
>>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>> {-# LANGUAGE OverlappingInstances #-}
>>> 
>>> and silently use an extension that the {build system, user, project} wanted to disallow, have we achieved anything? Compare this to the current situation, where the environment can say -XNoOverlappingInstances and code can override that with {-# LANGUAGE OverlappingInstances #-} - there's essentially no difference, we just added another layer of disable/override that isn't buying us anything.
>>> 
>>> (note I'm viewing this through the spectacles of -Werror, because I've come to believe that warnings are essentially not useful unless given teeth with -Werror.)
>>> 
>>> Cheers
>>> Simon
>>> 
>>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <vlad.z.4096 at gmail.com> wrote:
>>>> I agree that we need a categorisation of extension language flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the right set of labels. In fact, I wouldn't want to commit to any particular categorisation before we actually go through all the extensions in GHC and see for ourselves that they can be adequately categorized according to the proposed system.
>>>> 
>>>> The proposal says "classifications of individual language extensions will be left to a future proposal". Well, I am skeptical that this separation makes sense. I would much prefer if we were discussing a concrete categorisation proposal, not just a set of four labels whose implications I can't fully grasp.
>>>> 
>>>> Vlad
>>>> 
>>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>>>> 
>>>>> I would love to hear from you about this proposal.  *Please*. 
>>>>> 
>>>>> I plan to accept it unless I hear dissent.  But I would much rather have an explicit response from you than take silence as assent.  You are a member of the committee, after all!
>>>>> 
>>>>> My apologies if I have missed your reply
>>>>> 
>>>>> Simon
>> _______________________________________________
>> 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 moritz.angermann at gmail.com  Sat Sep  2 02:48:32 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 2 Sep 2023 10:48:32 +0800
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
Message-ID: <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>

This is a bit hard for me. But here it goes.

IMO _every_ extension enabled in the public release of GHC _are_ stable by
definition. It's a stable release, thus
the available extensions are also those the GHC team decides to be stable.
While I'm very much in favour of having
a clearer picture of what we currently consider extensions to be. I do not
believe _Unstable_ extensions should
ever be part of a public stable release. I also don't think the distinction
between Legacy and Deprecated is easy to
understand for the end user. Either the extension is supposed to be used,
or not. Stable or Deprecated. The fact that
we'll keep some extension around for what is effectively an infinite
deprecation period is a technicality in my opinion.

This puts my vote probably fairly square into Alternative 6.3; I don't
think 6.1 is useful. Having to tell people to RTFM
comes across pretty passive aggressive all the time. Also it's the
compiler's knowledge as to what is deprecated or not
and it should report this. 6.2 is even worse, as it now has two components
that need to be kept in sync, while the
extensions are pretty much integral to GHC. Hence GHC has this knowledge
and should report it. 6.4 and 6.5 are in
the same line as the Legacy/Deprecated extra complexity bucket to me.

Again, what's shipped in the stable release _is_ stable to me. And as such
any _unstable_ extensions should _not_
be in stable ghc releases. Other languages have separate channels for this.
I've also proposed multiple times to have
either two separate development branches: stable + experimental (stable
being periodically merged into experimental),
and cutting _stable_ releases from stable, potentially offering
_experimental_ releases from the experimental branch.
And alternative model is to have a single branch (as I do understand that
getting stuff from the experimental branch
migrated into stable could be a bit messy), but have every _unstable_
extension behind a -DEXPERIMENTAL compile
time flag. The same flag could be used to produce experimental ghc releases
for 3rd parties to consume.

Again, my point is that Unstable extensions should _not_ be in the Stable
ghc releases, and as such anything that's in
the stable ghc releases should be considered stable. If I want to play with
bleeding edge features, I should have to use
a completely separate compiler for this (again, other languages _do_ follow
this approach).

And that leaves us with stable extensions in GHC, for which we eventually
see that we have better facilities now or
learned over time that these extensions (despite being stable), have
reached their end of life. In that case they should
be marked as deprecated with appropriately long deprecation cycles.

GHC already has a ton of flags, let's try not to add that many more to it.
Ultimately someone needs to keep all of this
in their head, while also trying to get their job done. And for some this
job is 9-5, five days a week only; no late night
hacking sessions, no weekend projects; but instead soccer
practice, cycling, spending time with their family. If we want
to make haskell successful, we need to make sure that in that people can be
effective and productive and solve real
world problems in the 40hs they have per week; and not study manuals, or
flags (and if they see one of the many
unknown flags, go study those flags) more than absolutely necessary to get
work done.

In summary, I don't see myself supporting this proposal as it adds too much
complexity and sets in stone that unstable
extensions are part of a stable compiler. I'm happy to see that the "only
deprecations" option is listed as an alternative
in 6.3, even though I do not agree with the assessment that we need more
nuance for users. Extension in my opinion
should only be stable, or deprecated. And the end user should never see
unstable extensions, unless they _explicitly_
asked for an experimental/unstable compiler.

Moritz

On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:

> There's a non-normative and a normative component to this proposal.
>
> The non-normative piece says that there should be a categorization scheme
> for language extensions. That is inarguable in my opinion. The proposal
> also suggests an initial framework of four categories, which seems like a
> reasonable place to start. (Vlad says we should first figure out how to map
> all extensions to the categories; I disagree. We can iterate on the
> categories over time, as needed.)
>
> The normative piece of the proposal says that we should start warning on
> the use of any Deprecated, Unstable, or Legacy extensions. This seems like
> a reasonable ideal, but the practicality kind of hinges on the bucketing of
> specific extensions (and on Richard's question of how `default-language` is
> interpreted). The authors give some recommendations of how to bucket
> particular extensions, but it's not exhaustive and I also view it as the
> authors' desire rather than a specific commitment of the proposal.
>
> So in my view:
>
> * Yes, we should have a framework for categorizing the jungle of language
> extensions, and the proposal seems like a fine starting point.
> * Yes, we should have a set of warnings for users who would like to forbid
> certain categories of extensions.
> * We should probably defer any decisions about default enablement of
> warnings until we have a complete proposed categorization. And that
> discussion should include some analysis of the pervasiveness of
> "deprecated", "unstable", and "legacy" extensions so we can judge the
> amount of churn. Just like any other discussion about deprecation.
>
> Eric
>
> On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
> > I've just posted on the GitHub ticket. I remain against the proposal in
> > its current form, mostly because it means (if I understand correctly)
> > that everyone who says `default-language: Haskell2010` will get
> > warnings.
> >
> > Richard
> >
> >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
> >>
> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com> wrote:
> >>> A few things make this not a straightforward thumbs up for me, though
> I'm not strongly against.
> >>>
> >>> What is the interaction with GHC20xx? Presumably we want to say
> something like GHC20xx will never include any Deprecated or Legacy
> extensions? What about Unsable? if an extension transitions from Stable ->
> Legacy, would we remove it from the next GHC20xx?
> >>
> >> Ah, I just noticed that the proposal does say something about this:
> >>
> >>> For existing, or future, language sets such as `GHC2021` or
> `Haskell98`, it is expected that none of the contained extensions would be
> `Unstable`. However, this proposal does not seek to impose any particular
> policy on the inclusion of extensions into language sets - the developers
> and the steering committee are always in the best position to make a
> decision about a concrete extension and extension set.
> >>
> >> OK.
> >>
> >> Simon
> >>
> >>
> >>>
> >>> Something doesn't feel quite right about the warning system. If a
> module can start with
> >>>
> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
> >>> {-# LANGUAGE OverlappingInstances #-}
> >>>
> >>> and silently use an extension that the {build system, user, project}
> wanted to disallow, have we achieved anything? Compare this to the current
> situation, where the environment can say -XNoOverlappingInstances and code
> can override that with {-# LANGUAGE OverlappingInstances #-} - there's
> essentially no difference, we just added another layer of disable/override
> that isn't buying us anything.
> >>>
> >>> (note I'm viewing this through the spectacles of -Werror, because I've
> come to believe that warnings are essentially not useful unless given teeth
> with -Werror.)
> >>>
> >>> Cheers
> >>> Simon
> >>>
> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <
> vlad.z.4096 at gmail.com> wrote:
> >>>> I agree that we need a categorisation of extension language flags,
> but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the
> right set of labels. In fact, I wouldn't want to commit to any particular
> categorisation before we actually go through all the extensions in GHC and
> see for ourselves that they can be adequately categorized according to the
> proposed system.
> >>>>
> >>>> The proposal says "classifications of individual language extensions
> will be left to a future proposal". Well, I am skeptical that this
> separation makes sense. I would much prefer if we were discussing a
> concrete categorisation proposal, not just a set of four labels whose
> implications I can't fully grasp.
> >>>>
> >>>> Vlad
> >>>>
> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
> >>>>>
> >>>>> I would love to hear from you about this proposal.  *Please*.
> >>>>>
> >>>>> I plan to accept it unless I hear dissent.  But I would much rather
> have an explicit response from you than take silence as assent.  You are a
> member of the committee, after all!
> >>>>>
> >>>>> My apologies if I have missed your reply
> >>>>>
> >>>>> Simon
> >> _______________________________________________
> >> 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/20230902/51186f7a/attachment-0001.html>

From mail at joachim-breitner.de  Sat Sep  2 07:59:15 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Sep 2023 09:59:15 +0200
Subject: [ghc-steering-committee] #605: visible forall to work without
 ScopedTypeVariables, rec: accept
In-Reply-To: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
References: <3629a3ed10bedf7ad4270276de1b345c5d24cca2.camel@joachim-breitner.de>
Message-ID: <d57e09821910bd4b452a9cc9fff1eefad7b3dbfe.camel@joachim-breitner.de>

Hi,

Am Freitag, dem 25.08.2023 um 16:38 +0200 schrieb Joachim Breitner:
> I’ll shepherd this myself, and I suggest acceptance.

only positive feedback, merging.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sat Sep  2 08:01:39 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Sep 2023 10:01:39 +0200
Subject: [ghc-steering-committee] #607: Amend #281 (visible forall) and
 #378 (Design of DH) to clarify treatment of term variables in types (rec:
 accept)
In-Reply-To: <68450S.HDBN7L22NASR1@gmail.com>
References: <68450S.HDBN7L22NASR1@gmail.com>
Message-ID: <0da98f91fd63285225cdf9b3fe2d5cbe984c4f45.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 29.08.2023 um 08:48 +0200 schrieb Vladislav:
> I recommend to accept. Please share your thoughts either here or
> directly on GitHub.

all in support, merging.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sat Sep  2 08:09:53 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Sep 2023 10:09:53 +0200
Subject: [ghc-steering-committee]   GHC Steering Committee Status
Message-ID: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>

Dear Committee,

time for another status email, in particular because I need an up-to-date
update to get stats for Simon’s famous report at HIW on Monday. Hope to see
some of you there! Let’s see what has happened since July 3

 * Arnaud did round 3 of his language extension policy investigation. 

 * we were asked to review these proposals:
  
   #597: Constraints synonyms in deriving heads, Shepherd: Moritz
   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, Sepherd: Joachim
   #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
   #583: HasField redesign, Shepherd: Arnaud
   #609: (p1; p2) for or-patterns, Shepherd: Chris
   #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad
   #605: visible forall to work without ScopedTypeVariables, Shepherd: Joachim
   #601: Extension lifecycle, Shepherd: Simon PJ

 * we have a recommendation from the shepherd about:

   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept
   #605: visible forall to work without ScopedTypeVariables, rec: accept
   #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
   #583: HasField redesign, rec: accept
   #601: Extension lifecycle, rec: accept

 * we have sent the following proposals back to revision

   #601: Extension lifecycle

 * we decided about the following proposals

   #596: sized literals in Show, accept
   #581: Namespaces-specified Imports, accept
   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept
   #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
   #605: visible forall to work without ScopedTypeVariables, accept

So we currently have to act on the following 9 proposals, up one since
last time:

## Waiting for committee decision

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assigned to Baldur
      2022-10-02: Reassignd to Vlad
      2022-11-30: Vlad recommends rejection
      This needs to be picked up again, it has been lingering too long!

#536: Type-level literals as a sep language extension, Shepherd: Vlad
      2023-02-16 Assigned to Vlad
      2023-03-06 Vlad recommends acceptance
      Some hesitancy in the committee to introduce this extension,
      the ongoing policy clarification process might guide us, 
      but maybe we can resolve this earlier?

#583: HasField redesign, rec: accept
      2023-08-30 Arnaud recommends acceptance

## Waiting for shepherd recommendation

#526: Applicative Comprehensions, Shepherd: Simon M
      2022-10-08: Assigned to Simon M
      Simon, please cast your recommendation!

#585: Amend Or Patterns, Shepherd: Richard
      2023-04-11: Assigned to Richard
      There are votes on syntax going on, ran by Sebastian Graf.
      Maybe this should be in “needs revision” until they are through.
      Richard, I’ll leave this to you
#609 seems to be related, not sure if we need both.

#194: Updated partial type signatures, Shepherd: Eric
      2023-05-25: Came back from needs revision

#434: Fine-grained unused warnings, Shepherd: Chris
      2023-07-02: Assigned to Chris

#597: Constraints synonyms in deriving heads, Shepherd: Moritz
      2023-07-25: Assigned to Moritz

#608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
      2023-08-17: Assigned to Richard


Cheers,
Joachim




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


From simon.peytonjones at gmail.com  Sat Sep  2 13:44:54 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 2 Sep 2023 14:44:54 +0100
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>
References: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8r7OzTdtnb+z5FsHCeHC4Wuta8DXKYDUKkFajLHpwEDQ@mail.gmail.com>

Thanks Joachim.

Dear shepherds, it is bad for us to have a proposal under committee review
for months.  To unlock that, we need you to be proactive.  Please!

   - *Simon M*:  #526 Applicative comprehensions.  The author submitted it
   nearly a year ago!  8th October 2022.
   - *Richard*: #585/#609 Or patterns
   - *Richard*: #608 no implicit bindings with -XPatternSignatures
   - *Moritz*: #597 Constraint synonyms in deriving heads
   - *Chris*: #434 Unused warnings. Assigned back on 2nd July.
   - *Eric*: #194 partial type signatures.  Assigned way back, 25 May 23

Action needed.  Thanks!

Simon

On Sat, 2 Sept 2023 at 09:10, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> time for another status email, in particular because I need an up-to-date
> update to get stats for Simon’s famous report at HIW on Monday. Hope to see
> some of you there! Let’s see what has happened since July 3
>
>  * Arnaud did round 3 of his language extension policy investigation.
>
>  * we were asked to review these proposals:
>
>    #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions,
> Sepherd: Joachim
>    #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>    #583: HasField redesign, Shepherd: Arnaud
>    #609: (p1; p2) for or-patterns, Shepherd: Chris
>    #607: Amendments clarify treatment of term variables in types,
> Shepherd: Vlad
>    #605: visible forall to work without ScopedTypeVariables, Shepherd:
> Joachim
>    #601: Extension lifecycle, Shepherd: Simon PJ
>
>  * we have a recommendation from the shepherd about:
>
>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec:
> accept
>    #605: visible forall to work without ScopedTypeVariables, rec: accept
>    #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify
> treatment of term variables in types (rec: accept)
>    #583: HasField redesign, rec: accept
>    #601: Extension lifecycle, rec: accept
>
>  * we have sent the following proposals back to revision
>
>    #601: Extension lifecycle
>
>  * we decided about the following proposals
>
>    #596: sized literals in Show, accept
>    #581: Namespaces-specified Imports, accept
>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept
>    #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify
> treatment of term variables in types (rec: accept)
>    #605: visible forall to work without ScopedTypeVariables, accept
>
> So we currently have to act on the following 9 proposals, up one since
> last time:
>
> ## Waiting for committee decision
>
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>       2022-09-03: Assigned to Baldur
>       2022-10-02: Reassignd to Vlad
>       2022-11-30: Vlad recommends rejection
>       This needs to be picked up again, it has been lingering too long!
>
> #536: Type-level literals as a sep language extension, Shepherd: Vlad
>       2023-02-16 Assigned to Vlad
>       2023-03-06 Vlad recommends acceptance
>       Some hesitancy in the committee to introduce this extension,
>       the ongoing policy clarification process might guide us,
>       but maybe we can resolve this earlier?
>
> #583: HasField redesign, rec: accept
>       2023-08-30 Arnaud recommends acceptance
>
> ## Waiting for shepherd recommendation
>
> #526: Applicative Comprehensions, Shepherd: Simon M
>       2022-10-08: Assigned to Simon M
>       Simon, please cast your recommendation!
>
> #585: Amend Or Patterns, Shepherd: Richard
>       2023-04-11: Assigned to Richard
>       There are votes on syntax going on, ran by Sebastian Graf.
>       Maybe this should be in “needs revision” until they are through.
>       Richard, I’ll leave this to you
> #609 seems to be related, not sure if we need both.
>
> #194: Updated partial type signatures, Shepherd: Eric
>       2023-05-25: Came back from needs revision
>
> #434: Fine-grained unused warnings, Shepherd: Chris
>       2023-07-02: Assigned to Chris
>
> #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>       2023-07-25: Assigned to Moritz
>
> #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>       2023-08-17: Assigned to Richard
>
>
> 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/20230902/bca2db97/attachment.html>

From simon.peytonjones at gmail.com  Sat Sep  2 13:56:01 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 2 Sep 2023 14:56:01 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
Message-ID: <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>

>
> Again, my point is that Unstable extensions should _not_ be in the Stable
> ghc releases, and as such anything that's in
>
the stable ghc releases should be considered stable.
>

I don't agree with this. To follow your plan we would have to do this:

   - Release ghc-9.10
   - Release ghc-9.10-experimental
   - The two are bit-for-bit identical, except that in ghc-9.10 a bunch
   experimental extensions, available in ghc-9.10-experimental, are unavailable

This would clearly add to the overheads of a release, and add confusion in
the user base.  What would it gain that is not gained by supporting
-Werorr=XExperimental?  That is, if you don't want access to experimental
features, just make it an error to use them -- something this proposal
enables for the first time. I seex many costs but no benefits in having two
copies of the same compiler.

You clearly feel strongly about this so I feel I am missing something
important.

Maybe you want -Werror=XExerimental to be the default?  So that to use an
experimental feature the user would not only have to invoke it by name, but
also switch off the error its use triggers.  That would cause a huge amount
of transitional churn which users would hate us for, but I can see some
logic in it.

Simon

On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> This is a bit hard for me. But here it goes.
>
> IMO _every_ extension enabled in the public release of GHC _are_ stable by
> definition. It's a stable release, thus
> the available extensions are also those the GHC team decides to be stable.
> While I'm very much in favour of having
> a clearer picture of what we currently consider extensions to be. I do not
> believe _Unstable_ extensions should
> ever be part of a public stable release. I also don't think the
> distinction between Legacy and Deprecated is easy to
> understand for the end user. Either the extension is supposed to be used,
> or not. Stable or Deprecated. The fact that
> we'll keep some extension around for what is effectively an infinite
> deprecation period is a technicality in my opinion.
>
> This puts my vote probably fairly square into Alternative 6.3; I don't
> think 6.1 is useful. Having to tell people to RTFM
> comes across pretty passive aggressive all the time. Also it's the
> compiler's knowledge as to what is deprecated or not
> and it should report this. 6.2 is even worse, as it now has two components
> that need to be kept in sync, while the
> extensions are pretty much integral to GHC. Hence GHC has this knowledge
> and should report it. 6.4 and 6.5 are in
> the same line as the Legacy/Deprecated extra complexity bucket to me.
>
> Again, what's shipped in the stable release _is_ stable to me. And as such
> any _unstable_ extensions should _not_
> be in stable ghc releases. Other languages have separate channels for
> this. I've also proposed multiple times to have
> either two separate development branches: stable + experimental (stable
> being periodically merged into experimental),
> and cutting _stable_ releases from stable, potentially offering
> _experimental_ releases from the experimental branch.
> And alternative model is to have a single branch (as I do understand that
> getting stuff from the experimental branch
> migrated into stable could be a bit messy), but have every _unstable_
> extension behind a -DEXPERIMENTAL compile
> time flag. The same flag could be used to produce experimental ghc
> releases for 3rd parties to consume.
>
> Again, my point is that Unstable extensions should _not_ be in the Stable
> ghc releases, and as such anything that's in
> the stable ghc releases should be considered stable. If I want to play
> with bleeding edge features, I should have to use
> a completely separate compiler for this (again, other languages _do_
> follow this approach).
>
> And that leaves us with stable extensions in GHC, for which we eventually
> see that we have better facilities now or
> learned over time that these extensions (despite being stable), have
> reached their end of life. In that case they should
> be marked as deprecated with appropriately long deprecation cycles.
>
> GHC already has a ton of flags, let's try not to add that many more to it.
> Ultimately someone needs to keep all of this
> in their head, while also trying to get their job done. And for some this
> job is 9-5, five days a week only; no late night
> hacking sessions, no weekend projects; but instead soccer
> practice, cycling, spending time with their family. If we want
> to make haskell successful, we need to make sure that in that people can
> be effective and productive and solve real
> world problems in the 40hs they have per week; and not study manuals, or
> flags (and if they see one of the many
> unknown flags, go study those flags) more than absolutely necessary to get
> work done.
>
> In summary, I don't see myself supporting this proposal as it adds too
> much complexity and sets in stone that unstable
> extensions are part of a stable compiler. I'm happy to see that the "only
> deprecations" option is listed as an alternative
> in 6.3, even though I do not agree with the assessment that we need more
> nuance for users. Extension in my opinion
> should only be stable, or deprecated. And the end user should never see
> unstable extensions, unless they _explicitly_
> asked for an experimental/unstable compiler.
>
> Moritz
>
> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:
>
>> There's a non-normative and a normative component to this proposal.
>>
>> The non-normative piece says that there should be a categorization scheme
>> for language extensions. That is inarguable in my opinion. The proposal
>> also suggests an initial framework of four categories, which seems like a
>> reasonable place to start. (Vlad says we should first figure out how to map
>> all extensions to the categories; I disagree. We can iterate on the
>> categories over time, as needed.)
>>
>> The normative piece of the proposal says that we should start warning on
>> the use of any Deprecated, Unstable, or Legacy extensions. This seems like
>> a reasonable ideal, but the practicality kind of hinges on the bucketing of
>> specific extensions (and on Richard's question of how `default-language` is
>> interpreted). The authors give some recommendations of how to bucket
>> particular extensions, but it's not exhaustive and I also view it as the
>> authors' desire rather than a specific commitment of the proposal.
>>
>> So in my view:
>>
>> * Yes, we should have a framework for categorizing the jungle of language
>> extensions, and the proposal seems like a fine starting point.
>> * Yes, we should have a set of warnings for users who would like to
>> forbid certain categories of extensions.
>> * We should probably defer any decisions about default enablement of
>> warnings until we have a complete proposed categorization. And that
>> discussion should include some analysis of the pervasiveness of
>> "deprecated", "unstable", and "legacy" extensions so we can judge the
>> amount of churn. Just like any other discussion about deprecation.
>>
>> Eric
>>
>> On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>> > I've just posted on the GitHub ticket. I remain against the proposal in
>> > its current form, mostly because it means (if I understand correctly)
>> > that everyone who says `default-language: Haskell2010` will get
>> > warnings.
>> >
>> > Richard
>> >
>> >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>> >>
>> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com> wrote:
>> >>> A few things make this not a straightforward thumbs up for me, though
>> I'm not strongly against.
>> >>>
>> >>> What is the interaction with GHC20xx? Presumably we want to say
>> something like GHC20xx will never include any Deprecated or Legacy
>> extensions? What about Unsable? if an extension transitions from Stable ->
>> Legacy, would we remove it from the next GHC20xx?
>> >>
>> >> Ah, I just noticed that the proposal does say something about this:
>> >>
>> >>> For existing, or future, language sets such as `GHC2021` or
>> `Haskell98`, it is expected that none of the contained extensions would be
>> `Unstable`. However, this proposal does not seek to impose any particular
>> policy on the inclusion of extensions into language sets - the developers
>> and the steering committee are always in the best position to make a
>> decision about a concrete extension and extension set.
>> >>
>> >> OK.
>> >>
>> >> Simon
>> >>
>> >>
>> >>>
>> >>> Something doesn't feel quite right about the warning system. If a
>> module can start with
>> >>>
>> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>> >>> {-# LANGUAGE OverlappingInstances #-}
>> >>>
>> >>> and silently use an extension that the {build system, user, project}
>> wanted to disallow, have we achieved anything? Compare this to the current
>> situation, where the environment can say -XNoOverlappingInstances and code
>> can override that with {-# LANGUAGE OverlappingInstances #-} - there's
>> essentially no difference, we just added another layer of disable/override
>> that isn't buying us anything.
>> >>>
>> >>> (note I'm viewing this through the spectacles of -Werror, because
>> I've come to believe that warnings are essentially not useful unless given
>> teeth with -Werror.)
>> >>>
>> >>> Cheers
>> >>> Simon
>> >>>
>> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <
>> vlad.z.4096 at gmail.com> wrote:
>> >>>> I agree that we need a categorisation of extension language flags,
>> but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the
>> right set of labels. In fact, I wouldn't want to commit to any particular
>> categorisation before we actually go through all the extensions in GHC and
>> see for ourselves that they can be adequately categorized according to the
>> proposed system.
>> >>>>
>> >>>> The proposal says "classifications of individual language extensions
>> will be left to a future proposal". Well, I am skeptical that this
>> separation makes sense. I would much prefer if we were discussing a
>> concrete categorisation proposal, not just a set of four labels whose
>> implications I can't fully grasp.
>> >>>>
>> >>>> Vlad
>> >>>>
>> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>> >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>> >>>>>
>> >>>>> I would love to hear from you about this proposal.  *Please*.
>> >>>>>
>> >>>>> I plan to accept it unless I hear dissent.  But I would much rather
>> have an explicit response from you than take silence as assent.  You are a
>> member of the committee, after all!
>> >>>>>
>> >>>>> My apologies if I have missed your reply
>> >>>>>
>> >>>>> Simon
>> >> _______________________________________________
>> >> 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/20230902/32b3a64f/attachment-0001.html>

From adam at well-typed.com  Sat Sep  2 14:04:06 2023
From: adam at well-typed.com (Adam Gundry)
Date: Sat, 2 Sep 2023 15:04:06 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
Message-ID: <83f32541-3c88-8799-660a-1e75d6b63366@well-typed.com>

I'm in agreement with Eric here. Let's accept the proposal modulo the 
reservation that the default warning levels need to be decided in the 
follow-up proposal that categorises extensions. And we can always 
fine-tune the categories themselves at that point.

Moritz, I appreciate your view that mainline GHC releases shouldn't have 
any Unstable extensions, but we are a very long way from that point (and 
my sense is that getting there is neither practically possible nor 
desirable). Given that, I'd hope that this proposal is useful to you 
anyway: once the classification is done, at least it will be clearer 
which extensions are Unstable (and indeed you can argue for 
`-Werror=XUnstable`, or relatively easily produce GHC binaries for which 
that option is mandated).

I was originally sceptical of the Deprecated/Legacy distinction, but 
I've come to see it as useful. In my view:

  * Legacy means "don't use this for new code, but there's no strong 
reason to move away from it". NPlusKPatterns (and indeed Haskell98 
generally) is in this category.

  * Deprecated means "expect support for this to be removed in the 
future, because there are compelling reasons to do so and a migration 
path to a better alternative". I don't think we should use this often 
(if at all), but that's a discussion that we can best have on a 
case-by-case basis once the framework is established.

Yes, this is slightly more complex than a boolean distinction. But I 
think it's not that hard to communicate, and it allows us to discourage 
beginners from using legacy features while still committing to 
supporting them over the long term.

Cheers,

Adam



On 02/09/2023 03:48, Moritz Angermann wrote:
> This is a bit hard for me. But here it goes.
> 
> IMO _every_ extension enabled in the public release of GHC _are_ stable 
> by definition. It's a stable release, thus
> the available extensions are also those the GHC team decides to be 
> stable. While I'm very much in favour of having
> a clearer picture of what we currently consider extensions to be. I do 
> not believe _Unstable_ extensions should
> ever be part of a public stable release. I also don't think the 
> distinction between Legacy and Deprecated is easy to
> understand for the end user. Either the extension is supposed to be 
> used, or not. Stable or Deprecated. The fact that
> we'll keep some extension around for what is effectively an infinite 
> deprecation period is a technicality in my opinion.
> 
> This puts my vote probably fairly square into Alternative 6.3; I don't 
> think 6.1 is useful. Having to tell people to RTFM
> comes across pretty passive aggressive all the time. Also it's the 
> compiler's knowledge as to what is deprecated or not
> and it should report this. 6.2 is even worse, as it now has two 
> components that need to be kept in sync, while the
> extensions are pretty much integral to GHC. Hence GHC has this knowledge 
> and should report it. 6.4 and 6.5 are in
> the same line as the Legacy/Deprecated extra complexity bucket to me.
> 
> Again, what's shipped in the stable release _is_ stable to me. And as 
> such any _unstable_ extensions should _not_
> be in stable ghc releases. Other languages have separate channels for 
> this. I've also proposed multiple times to have
> either two separate development branches: stable + experimental (stable 
> being periodically merged into experimental),
> and cutting _stable_ releases from stable, potentially offering 
> _experimental_ releases from the experimental branch.
> And alternative model is to have a single branch (as I do understand 
> that getting stuff from the experimental branch
> migrated into stable could be a bit messy), but have every _unstable_ 
> extension behind a -DEXPERIMENTAL compile
> time flag. The same flag could be used to produce experimental ghc 
> releases for 3rd parties to consume.
> 
> Again, my point is that Unstable extensions should _not_ be in the 
> Stable ghc releases, and as such anything that's in
> the stable ghc releases should be considered stable. If I want to play 
> with bleeding edge features, I should have to use
> a completely separate compiler for this (again, other languages _do_ 
> follow this approach).
> 
> And that leaves us with stable extensions in GHC, for which we 
> eventually see that we have better facilities now or
> learned over time that these extensions (despite being stable), have 
> reached their end of life. In that case they should
> be marked as deprecated with appropriately long deprecation cycles.
> 
> GHC already has a ton of flags, let's try not to add that many more to 
> it. Ultimately someone needs to keep all of this
> in their head, while also trying to get their job done. And for some 
> this job is 9-5, five days a week only; no late night
> hacking sessions, no weekend projects; but instead soccer 
> practice, cycling, spending time with their family. If we want
> to make haskell successful, we need to make sure that in that people can 
> be effective and productive and solve real
> world problems in the 40hs they have per week; and not study manuals, or 
> flags (and if they see one of the many
> unknown flags, go study those flags) more than absolutely necessary to 
> get work done.
> 
> In summary, I don't see myself supporting this proposal as it adds too 
> much complexity and sets in stone that unstable
> extensions are part of a stable compiler. I'm happy to see that the 
> "only deprecations" option is listed as an alternative
> in 6.3, even though I do not agree with the assessment that we need more 
> nuance for users. Extension in my opinion
> should only be stable, or deprecated. And the end user should never see 
> unstable extensions, unless they _explicitly_
> asked for an experimental/unstable compiler.
> 
> Moritz
> 
> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io 
> <mailto:eric at seidel.io>> wrote:
> 
>     There's a non-normative and a normative component to this proposal.
> 
>     The non-normative piece says that there should be a categorization
>     scheme for language extensions. That is inarguable in my opinion.
>     The proposal also suggests an initial framework of four categories,
>     which seems like a reasonable place to start. (Vlad says we should
>     first figure out how to map all extensions to the categories; I
>     disagree. We can iterate on the categories over time, as needed.)
> 
>     The normative piece of the proposal says that we should start
>     warning on the use of any Deprecated, Unstable, or Legacy
>     extensions. This seems like a reasonable ideal, but the practicality
>     kind of hinges on the bucketing of specific extensions (and on
>     Richard's question of how `default-language` is interpreted). The
>     authors give some recommendations of how to bucket particular
>     extensions, but it's not exhaustive and I also view it as the
>     authors' desire rather than a specific commitment of the proposal.
> 
>     So in my view:
> 
>     * Yes, we should have a framework for categorizing the jungle of
>     language extensions, and the proposal seems like a fine starting point.
>     * Yes, we should have a set of warnings for users who would like to
>     forbid certain categories of extensions.
>     * We should probably defer any decisions about default enablement of
>     warnings until we have a complete proposed categorization. And that
>     discussion should include some analysis of the pervasiveness of
>     "deprecated", "unstable", and "legacy" extensions so we can judge
>     the amount of churn. Just like any other discussion about deprecation.
> 
>     Eric
> 
>     On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>      > I've just posted on the GitHub ticket. I remain against the
>     proposal in
>      > its current form, mostly because it means (if I understand
>     correctly)
>      > that everyone who says `default-language: Haskell2010` will get
>      > warnings.
>      >
>      > Richard
>      >
>      >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>> wrote:
>      >>
>      >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com
>     <mailto:marlowsd at gmail.com>> wrote:
>      >>> A few things make this not a straightforward thumbs up for me,
>     though I'm not strongly against.
>      >>>
>      >>> What is the interaction with GHC20xx? Presumably we want to say
>     something like GHC20xx will never include any Deprecated or Legacy
>     extensions? What about Unsable? if an extension transitions from
>     Stable -> Legacy, would we remove it from the next GHC20xx?
>      >>
>      >> Ah, I just noticed that the proposal does say something about this:
>      >>
>      >>> For existing, or future, language sets such as `GHC2021` or
>     `Haskell98`, it is expected that none of the contained extensions
>     would be `Unstable`. However, this proposal does not seek to impose
>     any particular policy on the inclusion of extensions into language
>     sets - the developers and the steering committee are always in the
>     best position to make a decision about a concrete extension and
>     extension set.
>      >>
>      >> OK.
>      >>
>      >> Simon
>      >>
>      >>
>      >>>
>      >>> Something doesn't feel quite right about the warning system. If
>     a module can start with
>      >>>
>      >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>      >>> {-# LANGUAGE OverlappingInstances #-}
>      >>>
>      >>> and silently use an extension that the {build system, user,
>     project} wanted to disallow, have we achieved anything? Compare this
>     to the current situation, where the environment can say
>     -XNoOverlappingInstances and code can override that with {-#
>     LANGUAGE OverlappingInstances #-} - there's essentially no
>     difference, we just added another layer of disable/override that
>     isn't buying us anything.
>      >>>
>      >>> (note I'm viewing this through the spectacles of -Werror,
>     because I've come to believe that warnings are essentially not
>     useful unless given teeth with -Werror.)
>      >>>
>      >>> Cheers
>      >>> Simon
>      >>>
>      >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov
>     <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
>      >>>> I agree that we need a categorisation of extension language
>     flags, but I'm not convinced that {Stable, Unstable, Deprecated,
>     Legacy} is the right set of labels. In fact, I wouldn't want to
>     commit to any particular categorisation before we actually go
>     through all the extensions in GHC and see for ourselves that they
>     can be adequately categorized according to the proposed system.
>      >>>>
>      >>>> The proposal says "classifications of individual language
>     extensions will be left to a future proposal". Well, I am skeptical
>     that this separation makes sense. I would much prefer if we were
>     discussing a concrete categorisation proposal, not just a set of
>     four labels whose implications I can't fully grasp.
>      >>>>
>      >>>> Vlad
>      >>>>
>      >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones
>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>     wrote:
>      >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>      >>>>>
>      >>>>> I would love to hear from you about this proposal.  *Please*.
>      >>>>>
>      >>>>> I plan to accept it unless I hear dissent.  But I would much
>     rather have an explicit response from you than take silence as
>     assent.  You are a member of the committee, after all!
>      >>>>>
>      >>>>> My apologies if I have missed your reply
>      >>>>>
>      >>>>> Simon


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From eric at seidel.io  Sat Sep  2 15:23:17 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 2 Sep 2023 11:23:17 -0400
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <83f32541-3c88-8799-660a-1e75d6b63366@well-typed.com>
References: <83f32541-3c88-8799-660a-1e75d6b63366@well-typed.com>
Message-ID: <F741612E-F62B-4DDF-9639-08FCE302A1CD@seidel.io>

As a general principle, a deprecated feature should have an “end-of-life” date, ie when we expect to remove the feature entirely. Is a “legacy” feature just a deprecated feature with no (current) end-of-life date?

Sent from my iPhone

> On Sep 2, 2023, at 10:04, Adam Gundry <adam at well-typed.com> wrote:
> 
> I'm in agreement with Eric here. Let's accept the proposal modulo the reservation that the default warning levels need to be decided in the follow-up proposal that categorises extensions. And we can always fine-tune the categories themselves at that point.
> 
> Moritz, I appreciate your view that mainline GHC releases shouldn't have any Unstable extensions, but we are a very long way from that point (and my sense is that getting there is neither practically possible nor desirable). Given that, I'd hope that this proposal is useful to you anyway: once the classification is done, at least it will be clearer which extensions are Unstable (and indeed you can argue for `-Werror=XUnstable`, or relatively easily produce GHC binaries for which that option is mandated).
> 
> I was originally sceptical of the Deprecated/Legacy distinction, but I've come to see it as useful. In my view:
> 
> * Legacy means "don't use this for new code, but there's no strong reason to move away from it". NPlusKPatterns (and indeed Haskell98 generally) is in this category.
> 
> * Deprecated means "expect support for this to be removed in the future, because there are compelling reasons to do so and a migration path to a better alternative". I don't think we should use this often (if at all), but that's a discussion that we can best have on a case-by-case basis once the framework is established.
> 
> Yes, this is slightly more complex than a boolean distinction. But I think it's not that hard to communicate, and it allows us to discourage beginners from using legacy features while still committing to supporting them over the long term.
> 
> Cheers,
> 
> Adam
> 
> 
> 
>> On 02/09/2023 03:48, Moritz Angermann wrote:
>> This is a bit hard for me. But here it goes.
>> IMO _every_ extension enabled in the public release of GHC _are_ stable by definition. It's a stable release, thus
>> the available extensions are also those the GHC team decides to be stable. While I'm very much in favour of having
>> a clearer picture of what we currently consider extensions to be. I do not believe _Unstable_ extensions should
>> ever be part of a public stable release. I also don't think the distinction between Legacy and Deprecated is easy to
>> understand for the end user. Either the extension is supposed to be used, or not. Stable or Deprecated. The fact that
>> we'll keep some extension around for what is effectively an infinite deprecation period is a technicality in my opinion.
>> This puts my vote probably fairly square into Alternative 6.3; I don't think 6.1 is useful. Having to tell people to RTFM
>> comes across pretty passive aggressive all the time. Also it's the compiler's knowledge as to what is deprecated or not
>> and it should report this. 6.2 is even worse, as it now has two components that need to be kept in sync, while the
>> extensions are pretty much integral to GHC. Hence GHC has this knowledge and should report it. 6.4 and 6.5 are in
>> the same line as the Legacy/Deprecated extra complexity bucket to me.
>> Again, what's shipped in the stable release _is_ stable to me. And as such any _unstable_ extensions should _not_
>> be in stable ghc releases. Other languages have separate channels for this. I've also proposed multiple times to have
>> either two separate development branches: stable + experimental (stable being periodically merged into experimental),
>> and cutting _stable_ releases from stable, potentially offering _experimental_ releases from the experimental branch.
>> And alternative model is to have a single branch (as I do understand that getting stuff from the experimental branch
>> migrated into stable could be a bit messy), but have every _unstable_ extension behind a -DEXPERIMENTAL compile
>> time flag. The same flag could be used to produce experimental ghc releases for 3rd parties to consume.
>> Again, my point is that Unstable extensions should _not_ be in the Stable ghc releases, and as such anything that's in
>> the stable ghc releases should be considered stable. If I want to play with bleeding edge features, I should have to use
>> a completely separate compiler for this (again, other languages _do_ follow this approach).
>> And that leaves us with stable extensions in GHC, for which we eventually see that we have better facilities now or
>> learned over time that these extensions (despite being stable), have reached their end of life. In that case they should
>> be marked as deprecated with appropriately long deprecation cycles.
>> GHC already has a ton of flags, let's try not to add that many more to it. Ultimately someone needs to keep all of this
>> in their head, while also trying to get their job done. And for some this job is 9-5, five days a week only; no late night
>> hacking sessions, no weekend projects; but instead soccer practice, cycling, spending time with their family. If we want
>> to make haskell successful, we need to make sure that in that people can be effective and productive and solve real
>> world problems in the 40hs they have per week; and not study manuals, or flags (and if they see one of the many
>> unknown flags, go study those flags) more than absolutely necessary to get work done.
>> In summary, I don't see myself supporting this proposal as it adds too much complexity and sets in stone that unstable
>> extensions are part of a stable compiler. I'm happy to see that the "only deprecations" option is listed as an alternative
>> in 6.3, even though I do not agree with the assessment that we need more nuance for users. Extension in my opinion
>> should only be stable, or deprecated. And the end user should never see unstable extensions, unless they _explicitly_
>> asked for an experimental/unstable compiler.
>> Moritz
>> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>    There's a non-normative and a normative component to this proposal.
>>    The non-normative piece says that there should be a categorization
>>    scheme for language extensions. That is inarguable in my opinion.
>>    The proposal also suggests an initial framework of four categories,
>>    which seems like a reasonable place to start. (Vlad says we should
>>    first figure out how to map all extensions to the categories; I
>>    disagree. We can iterate on the categories over time, as needed.)
>>    The normative piece of the proposal says that we should start
>>    warning on the use of any Deprecated, Unstable, or Legacy
>>    extensions. This seems like a reasonable ideal, but the practicality
>>    kind of hinges on the bucketing of specific extensions (and on
>>    Richard's question of how `default-language` is interpreted). The
>>    authors give some recommendations of how to bucket particular
>>    extensions, but it's not exhaustive and I also view it as the
>>    authors' desire rather than a specific commitment of the proposal.
>>    So in my view:
>>    * Yes, we should have a framework for categorizing the jungle of
>>    language extensions, and the proposal seems like a fine starting point.
>>    * Yes, we should have a set of warnings for users who would like to
>>    forbid certain categories of extensions.
>>    * We should probably defer any decisions about default enablement of
>>    warnings until we have a complete proposed categorization. And that
>>    discussion should include some analysis of the pervasiveness of
>>    "deprecated", "unstable", and "legacy" extensions so we can judge
>>    the amount of churn. Just like any other discussion about deprecation.
>>    Eric
>>    On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>>     > I've just posted on the GitHub ticket. I remain against the
>>    proposal in
>>     > its current form, mostly because it means (if I understand
>>    correctly)
>>     > that everyone who says `default-language: Haskell2010` will get
>>     > warnings.
>>     >
>>     > Richard
>>     >
>>     >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com
>>    <mailto:marlowsd at gmail.com>> wrote:
>>     >>
>>     >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com
>>    <mailto:marlowsd at gmail.com>> wrote:
>>     >>> A few things make this not a straightforward thumbs up for me,
>>    though I'm not strongly against.
>>     >>>
>>     >>> What is the interaction with GHC20xx? Presumably we want to say
>>    something like GHC20xx will never include any Deprecated or Legacy
>>    extensions? What about Unsable? if an extension transitions from
>>    Stable -> Legacy, would we remove it from the next GHC20xx?
>>     >>
>>     >> Ah, I just noticed that the proposal does say something about this:
>>     >>
>>     >>> For existing, or future, language sets such as `GHC2021` or
>>    `Haskell98`, it is expected that none of the contained extensions
>>    would be `Unstable`. However, this proposal does not seek to impose
>>    any particular policy on the inclusion of extensions into language
>>    sets - the developers and the steering committee are always in the
>>    best position to make a decision about a concrete extension and
>>    extension set.
>>     >>
>>     >> OK.
>>     >>
>>     >> Simon
>>     >>
>>     >>
>>     >>>
>>     >>> Something doesn't feel quite right about the warning system. If
>>    a module can start with
>>     >>>
>>     >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>     >>> {-# LANGUAGE OverlappingInstances #-}
>>     >>>
>>     >>> and silently use an extension that the {build system, user,
>>    project} wanted to disallow, have we achieved anything? Compare this
>>    to the current situation, where the environment can say
>>    -XNoOverlappingInstances and code can override that with {-#
>>    LANGUAGE OverlappingInstances #-} - there's essentially no
>>    difference, we just added another layer of disable/override that
>>    isn't buying us anything.
>>     >>>
>>     >>> (note I'm viewing this through the spectacles of -Werror,
>>    because I've come to believe that warnings are essentially not
>>    useful unless given teeth with -Werror.)
>>     >>>
>>     >>> Cheers
>>     >>> Simon
>>     >>>
>>     >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov
>>    <vlad.z.4096 at gmail.com <mailto:vlad.z.4096 at gmail.com>> wrote:
>>     >>>> I agree that we need a categorisation of extension language
>>    flags, but I'm not convinced that {Stable, Unstable, Deprecated,
>>    Legacy} is the right set of labels. In fact, I wouldn't want to
>>    commit to any particular categorisation before we actually go
>>    through all the extensions in GHC and see for ourselves that they
>>    can be adequately categorized according to the proposed system.
>>     >>>>
>>     >>>> The proposal says "classifications of individual language
>>    extensions will be left to a future proposal". Well, I am skeptical
>>    that this separation makes sense. I would much prefer if we were
>>    discussing a concrete categorisation proposal, not just a set of
>>    four labels whose implications I can't fully grasp.
>>     >>>>
>>     >>>> Vlad
>>     >>>>
>>     >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones
>>    <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>    wrote:
>>     >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>     >>>>>
>>     >>>>> I would love to hear from you about this proposal.  *Please*.
>>     >>>>>
>>     >>>>> I plan to accept it unless I hear dissent.  But I would much
>>    rather have an explicit response from you than take silence as
>>    assent.  You are a member of the committee, after all!
>>     >>>>>
>>     >>>>> My apologies if I have missed your reply
>>     >>>>>
>>     >>>>> Simon
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
> 
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> 
> _______________________________________________
> 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  2 19:39:06 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 02 Sep 2023 15:39:06 -0400
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <CAJKmMz8r7OzTdtnb+z5FsHCeHC4Wuta8DXKYDUKkFajLHpwEDQ@mail.gmail.com>
References: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>
 <CAJKmMz8r7OzTdtnb+z5FsHCeHC4Wuta8DXKYDUKkFajLHpwEDQ@mail.gmail.com>
Message-ID: <afd28b2c-682f-4b9f-bfbe-3ff62d061263@app.fastmail.com>

>  Eric: #194 partial type signatures.  Assigned way back, 25 May 23

Apologies, I think I botched the process on this one. I left feedback on the proposal a while back but did not synthesize my feedback to the Committee ML. Will do so now.

On Sat, Sep 2, 2023, at 09:44, Simon Peyton Jones wrote:
> Thanks Joachim.
>
> Dear shepherds, it is bad for us to have a proposal under committee 
> review for months.  To unlock that, we need you to be proactive.  
> Please!
>  • *Simon M*:  #526 Applicative comprehensions.  The author submitted 
> it nearly a year ago!  8th October 2022.
>  • *Richard*: #585/#609 Or patterns
>  • *Richard*: #608 no implicit bindings with -XPatternSignatures
>  • *Moritz*: #597 Constraint synonyms in deriving heads
>  • *Chris*: #434 Unused warnings. Assigned back on 2nd July.
>  • *Eric*: #194 partial type signatures.  Assigned way back, 25 May 23
> Action needed.  Thanks!
>
> Simon
>
> On Sat, 2 Sept 2023 at 09:10, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> Dear Committee,
>> 
>> time for another status email, in particular because I need an up-to-date
>> update to get stats for Simon’s famous report at HIW on Monday. Hope to see
>> some of you there! Let’s see what has happened since July 3
>> 
>>  * Arnaud did round 3 of his language extension policy investigation. 
>> 
>>  * we were asked to review these proposals:
>> 
>>    #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, Sepherd: Joachim
>>    #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>>    #583: HasField redesign, Shepherd: Arnaud
>>    #609: (p1; p2) for or-patterns, Shepherd: Chris
>>    #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad
>>    #605: visible forall to work without ScopedTypeVariables, Shepherd: Joachim
>>    #601: Extension lifecycle, Shepherd: Simon PJ
>> 
>>  * we have a recommendation from the shepherd about:
>> 
>>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept
>>    #605: visible forall to work without ScopedTypeVariables, rec: accept
>>    #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
>>    #583: HasField redesign, rec: accept
>>    #601: Extension lifecycle, rec: accept
>> 
>>  * we have sent the following proposals back to revision
>> 
>>    #601: Extension lifecycle
>> 
>>  * we decided about the following proposals
>> 
>>    #596: sized literals in Show, accept
>>    #581: Namespaces-specified Imports, accept
>>    #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept
>>    #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
>>    #605: visible forall to work without ScopedTypeVariables, accept
>> 
>> So we currently have to act on the following 9 proposals, up one since
>> last time:
>> 
>> ## Waiting for committee decision
>> 
>> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>>       2022-09-03: Assigned to Baldur
>>       2022-10-02: Reassignd to Vlad
>>       2022-11-30: Vlad recommends rejection
>>       This needs to be picked up again, it has been lingering too long!
>> 
>> #536: Type-level literals as a sep language extension, Shepherd: Vlad
>>       2023-02-16 Assigned to Vlad
>>       2023-03-06 Vlad recommends acceptance
>>       Some hesitancy in the committee to introduce this extension,
>>       the ongoing policy clarification process might guide us, 
>>       but maybe we can resolve this earlier?
>> 
>> #583: HasField redesign, rec: accept
>>       2023-08-30 Arnaud recommends acceptance
>> 
>> ## Waiting for shepherd recommendation
>> 
>> #526: Applicative Comprehensions, Shepherd: Simon M
>>       2022-10-08: Assigned to Simon M
>>       Simon, please cast your recommendation!
>> 
>> #585: Amend Or Patterns, Shepherd: Richard
>>       2023-04-11: Assigned to Richard
>>       There are votes on syntax going on, ran by Sebastian Graf.
>>       Maybe this should be in “needs revision” until they are through.
>>       Richard, I’ll leave this to you
>> #609 seems to be related, not sure if we need both.
>> 
>> #194: Updated partial type signatures, Shepherd: Eric
>>       2023-05-25: Came back from needs revision
>> 
>> #434: Fine-grained unused warnings, Shepherd: Chris
>>       2023-07-02: Assigned to Chris
>> 
>> #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>>       2023-07-25: Assigned to Moritz
>> 
>> #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>>       2023-08-17: Assigned to Richard
>> 
>> 
>> 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

From eric at seidel.io  Sat Sep  2 20:05:21 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 02 Sep 2023 16:05:21 -0400
Subject: [ghc-steering-committee] Please review #194: Updated partial
 type signatures, Recommendation: Reject
In-Reply-To: <360e9bcad56908e7e3d77e3320de6cd06050928a.camel@joachim-breitner.de>
References: <360e9bcad56908e7e3d77e3320de6cd06050928a.camel@joachim-breitner.de>
Message-ID: <f878599e-5b9c-4724-8896-29ef65d95b8f@app.fastmail.com>

Dear Committee,

Richard has proposed an update to the PartialTypeSignatures extension. The proposal is quite detailed and I recommend the Committee read the whole thing as my summary will not do it justice. But the gist is that the `_` has acquired many different meanings in Haskell in different syntactic contexts and under different sets of extensions. And the result is quite confusing! Richard describes four different meanings of `_` in the proposal.

But I don't think Richard's proposal does enough to remedy the situation. I still find the proposed change hard to reason about and would prefer to further simplify the language here.

I suggested an alternate direction[1] on GitHub that I think would make a meaningful improvement. Looking back at the proposal again, it may not be as far from Richard's proposal as I had originally thought. But I think it is important to have different syntax to express the two modalities of "I don't care" (elision/wildcard) and "I don't know" (hole/query).

My recommendation is to not accept this proposal in its current form.

Eric

[1]: https://github.com/ghc-proposals/ghc-proposals/pull/194#discussion_r1257517608

On Thu, May 25, 2023, at 01:55, Joachim Breitner wrote:
> Dear Committee,
>
> Richard resubmits updated partial type signatures:
>
> https://github.com/ghc-proposals/ghc-proposals/pull/194
>
> https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/proposals/0000-updated-partial-type-sigs.rst
>
> I’d like to ask Eric to shepherd this proposal.
>
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
>
> 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 mail at joachim-breitner.de  Sat Sep  2 21:34:57 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Sep 2023 23:34:57 +0200
Subject: [ghc-steering-committee] Please review #194: Updated partial
 type signatures, Recommendation: Reject
In-Reply-To: <f878599e-5b9c-4724-8896-29ef65d95b8f@app.fastmail.com>
References: <360e9bcad56908e7e3d77e3320de6cd06050928a.camel@joachim-breitner.de>
 <f878599e-5b9c-4724-8896-29ef65d95b8f@app.fastmail.com>
Message-ID: <f4de105e96bb0051b576e772726de30fe3bfbcff.camel@joachim-breitner.de>

Hi,

Am Samstag, dem 02.09.2023 um 16:05 -0400 schrieb Eric Seidel:
> My recommendation is to not accept this proposal in its current form.

is that more a hard reject (i.e. we don't encourage anyone to work on
that proposal anymore), or a more a soft “needs revision”?

Cheers,
Joachim

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


From moritz.angermann at gmail.com  Sun Sep  3 00:15:39 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 3 Sep 2023 08:15:39 +0800
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
 <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
Message-ID: <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>

On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Again, my point is that Unstable extensions should _not_ be in the Stable
>> ghc releases, and as such anything that's in
>>
> the stable ghc releases should be considered stable.
>>
>
> I don't agree with this. To follow your plan we would have to do this:
>
>    - Release ghc-9.10
>    - Release ghc-9.10-experimental
>    - The two are bit-for-bit identical, except that in ghc-9.10 a bunch
>    experimental extensions, available in ghc-9.10-experimental, are unavailable
>
> I do not consider this significantly more work it’s really just passing
-DEXPERIMENTAL to the build. But we don’t even need those during our
_stable_ build releases. We have nighties and we could build nightlies with
-DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can
get them through nightly builds.

This is also what other languages do.

You clearly feel strongly about this so I feel I am missing something
> important.
>

Yes, very much so.

Maybe you want -Werror=XExerimental to be the default?  So that to use an
> experimental feature the user would not only have to invoke it by name, but
> also switch off the error its use triggers.  That would cause a huge amount
> of transitional churn which users would hate us for, but I can see some
> logic in it.
>

That’s why I’m advocating for a separate build. So they don’t get any
warning and can enable the features to their heats content. But if you do
not use the experimental build (e.g. a nightly) you can not, not even by
accident, enable those features.

By having them in release builds you open the door to lengthy discussions
of why some features a _stable_ compiler offers should _not_ be used. And
then have to have reviewers be careful about which extensions and other
features are enabled or not. It basically puts a lot of work on teams to
reign in on accidental usage of experimental/unstable features. So then we
end up building tools on-top, lingers, CI checks to run with
-Werror=XExerimental, … all just to ensure something which should not be
there by construction.

I simply do not believe that experimental or unstable features should be
part of stable releases. What is the definition of stable at that point?

The practice that we put experimental/unstable features into our stable
releases is something this proposal seems to cement, which is why I’m so
much against it in this form. I fundamentally believe that if we put
experimental/unstable features into our releases we must not call them
stable releases. So we are left with experimental/unstable releases only.

We’ve had discussions around this before:
- Michael Snoymans Boring Haskell[1]
- Simple Haskell[2]
- George Wilson’s talk on Cultivating an Engineering Dialect[3]

I hope this helps clarify my stance on this proposal.

Moritz

—
[1]:
https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/
[2]:
https://www.simplehaskell.org
[3]: https://www.youtube.com/watch?v=L4h6VegK1BI


On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> This is a bit hard for me. But here it goes.
>>
>> IMO _every_ extension enabled in the public release of GHC _are_ stable
>> by definition. It's a stable release, thus
>> the available extensions are also those the GHC team decides to be
>> stable. While I'm very much in favour of having
>> a clearer picture of what we currently consider extensions to be. I do
>> not believe _Unstable_ extensions should
>> ever be part of a public stable release. I also don't think the
>> distinction between Legacy and Deprecated is easy to
>> understand for the end user. Either the extension is supposed to be used,
>> or not. Stable or Deprecated. The fact that
>> we'll keep some extension around for what is effectively an infinite
>> deprecation period is a technicality in my opinion.
>>
>> This puts my vote probably fairly square into Alternative 6.3; I don't
>> think 6.1 is useful. Having to tell people to RTFM
>> comes across pretty passive aggressive all the time. Also it's the
>> compiler's knowledge as to what is deprecated or not
>> and it should report this. 6.2 is even worse, as it now has two
>> components that need to be kept in sync, while the
>> extensions are pretty much integral to GHC. Hence GHC has this knowledge
>> and should report it. 6.4 and 6.5 are in
>> the same line as the Legacy/Deprecated extra complexity bucket to me.
>>
>> Again, what's shipped in the stable release _is_ stable to me. And as
>> such any _unstable_ extensions should _not_
>> be in stable ghc releases. Other languages have separate channels for
>> this. I've also proposed multiple times to have
>> either two separate development branches: stable + experimental (stable
>> being periodically merged into experimental),
>> and cutting _stable_ releases from stable, potentially offering
>> _experimental_ releases from the experimental branch.
>> And alternative model is to have a single branch (as I do understand that
>> getting stuff from the experimental branch
>> migrated into stable could be a bit messy), but have every _unstable_
>> extension behind a -DEXPERIMENTAL compile
>> time flag. The same flag could be used to produce experimental ghc
>> releases for 3rd parties to consume.
>>
>> Again, my point is that Unstable extensions should _not_ be in the Stable
>> ghc releases, and as such anything that's in
>> the stable ghc releases should be considered stable. If I want to play
>> with bleeding edge features, I should have to use
>> a completely separate compiler for this (again, other languages _do_
>> follow this approach).
>>
>> And that leaves us with stable extensions in GHC, for which we eventually
>> see that we have better facilities now or
>> learned over time that these extensions (despite being stable), have
>> reached their end of life. In that case they should
>> be marked as deprecated with appropriately long deprecation cycles.
>>
>> GHC already has a ton of flags, let's try not to add that many more to
>> it. Ultimately someone needs to keep all of this
>> in their head, while also trying to get their job done. And for some this
>> job is 9-5, five days a week only; no late night
>> hacking sessions, no weekend projects; but instead soccer
>> practice, cycling, spending time with their family. If we want
>> to make haskell successful, we need to make sure that in that people can
>> be effective and productive and solve real
>> world problems in the 40hs they have per week; and not study manuals, or
>> flags (and if they see one of the many
>> unknown flags, go study those flags) more than absolutely necessary to
>> get work done.
>>
>> In summary, I don't see myself supporting this proposal as it adds too
>> much complexity and sets in stone that unstable
>> extensions are part of a stable compiler. I'm happy to see that the "only
>> deprecations" option is listed as an alternative
>> in 6.3, even though I do not agree with the assessment that we need more
>> nuance for users. Extension in my opinion
>> should only be stable, or deprecated. And the end user should never see
>> unstable extensions, unless they _explicitly_
>> asked for an experimental/unstable compiler.
>>
>> Moritz
>>
>> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:
>>
>>> There's a non-normative and a normative component to this proposal.
>>>
>>> The non-normative piece says that there should be a categorization
>>> scheme for language extensions. That is inarguable in my opinion. The
>>> proposal also suggests an initial framework of four categories, which seems
>>> like a reasonable place to start. (Vlad says we should first figure out how
>>> to map all extensions to the categories; I disagree. We can iterate on the
>>> categories over time, as needed.)
>>>
>>> The normative piece of the proposal says that we should start warning on
>>> the use of any Deprecated, Unstable, or Legacy extensions. This seems like
>>> a reasonable ideal, but the practicality kind of hinges on the bucketing of
>>> specific extensions (and on Richard's question of how `default-language` is
>>> interpreted). The authors give some recommendations of how to bucket
>>> particular extensions, but it's not exhaustive and I also view it as the
>>> authors' desire rather than a specific commitment of the proposal.
>>>
>>> So in my view:
>>>
>>> * Yes, we should have a framework for categorizing the jungle of
>>> language extensions, and the proposal seems like a fine starting point.
>>> * Yes, we should have a set of warnings for users who would like to
>>> forbid certain categories of extensions.
>>> * We should probably defer any decisions about default enablement of
>>> warnings until we have a complete proposed categorization. And that
>>> discussion should include some analysis of the pervasiveness of
>>> "deprecated", "unstable", and "legacy" extensions so we can judge the
>>> amount of churn. Just like any other discussion about deprecation.
>>>
>>> Eric
>>>
>>> On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>>> > I've just posted on the GitHub ticket. I remain against the proposal
>>> in
>>> > its current form, mostly because it means (if I understand correctly)
>>> > that everyone who says `default-language: Haskell2010` will get
>>> > warnings.
>>> >
>>> > Richard
>>> >
>>> >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>>> >>
>>> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com>
>>> wrote:
>>> >>> A few things make this not a straightforward thumbs up for me,
>>> though I'm not strongly against.
>>> >>>
>>> >>> What is the interaction with GHC20xx? Presumably we want to say
>>> something like GHC20xx will never include any Deprecated or Legacy
>>> extensions? What about Unsable? if an extension transitions from Stable ->
>>> Legacy, would we remove it from the next GHC20xx?
>>> >>
>>> >> Ah, I just noticed that the proposal does say something about this:
>>> >>
>>> >>> For existing, or future, language sets such as `GHC2021` or
>>> `Haskell98`, it is expected that none of the contained extensions would be
>>> `Unstable`. However, this proposal does not seek to impose any particular
>>> policy on the inclusion of extensions into language sets - the developers
>>> and the steering committee are always in the best position to make a
>>> decision about a concrete extension and extension set.
>>> >>
>>> >> OK.
>>> >>
>>> >> Simon
>>> >>
>>> >>
>>> >>>
>>> >>> Something doesn't feel quite right about the warning system. If a
>>> module can start with
>>> >>>
>>> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>> >>> {-# LANGUAGE OverlappingInstances #-}
>>> >>>
>>> >>> and silently use an extension that the {build system, user, project}
>>> wanted to disallow, have we achieved anything? Compare this to the current
>>> situation, where the environment can say -XNoOverlappingInstances and code
>>> can override that with {-# LANGUAGE OverlappingInstances #-} - there's
>>> essentially no difference, we just added another layer of disable/override
>>> that isn't buying us anything.
>>> >>>
>>> >>> (note I'm viewing this through the spectacles of -Werror, because
>>> I've come to believe that warnings are essentially not useful unless given
>>> teeth with -Werror.)
>>> >>>
>>> >>> Cheers
>>> >>> Simon
>>> >>>
>>> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <
>>> vlad.z.4096 at gmail.com> wrote:
>>> >>>> I agree that we need a categorisation of extension language flags,
>>> but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the
>>> right set of labels. In fact, I wouldn't want to commit to any particular
>>> categorisation before we actually go through all the extensions in GHC and
>>> see for ourselves that they can be adequately categorized according to the
>>> proposed system.
>>> >>>>
>>> >>>> The proposal says "classifications of individual language
>>> extensions will be left to a future proposal". Well, I am skeptical that
>>> this separation makes sense. I would much prefer if we were discussing a
>>> concrete categorisation proposal, not just a set of four labels whose
>>> implications I can't fully grasp.
>>> >>>>
>>> >>>> Vlad
>>> >>>>
>>> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>> >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>> >>>>>
>>> >>>>> I would love to hear from you about this proposal.  *Please*.
>>> >>>>>
>>> >>>>> I plan to accept it unless I hear dissent.  But I would much
>>> rather have an explicit response from you than take silence as assent.  You
>>> are a member of the committee, after all!
>>> >>>>>
>>> >>>>> My apologies if I have missed your reply
>>> >>>>>
>>> >>>>> Simon
>>> >> _______________________________________________
>>> >> 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/20230903/7bd27639/attachment-0001.html>

From eric at seidel.io  Sun Sep  3 00:35:01 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 2 Sep 2023 20:35:01 -0400
Subject: [ghc-steering-committee] Please review #194: Updated partial
	type signatures, Recommendation: Reject
In-Reply-To: <f4de105e96bb0051b576e772726de30fe3bfbcff.camel@joachim-breitner.de>
References: <f4de105e96bb0051b576e772726de30fe3bfbcff.camel@joachim-breitner.de>
Message-ID: <E757BC45-5EF9-45F5-9AF8-127D54801223@seidel.io>

Needs revision. I do think this is a problem worth solving!

Sent from my iPhone

> On Sep 2, 2023, at 17:35, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
>> Am Samstag, dem 02.09.2023 um 16:05 -0400 schrieb Eric Seidel:
>> My recommendation is to not accept this proposal in its current form.
> 
> is that more a hard reject (i.e. we don't encourage anyone to work on
> that proposal anymore), or a more a soft “needs revision”?
> 
> 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 mail at joachim-breitner.de  Sun Sep  3 01:19:23 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 02 Sep 2023 18:19:23 -0700
Subject: [ghc-steering-committee] Please review #194: Updated partial
 type signatures, Recommendation: Reject
In-Reply-To: <E757BC45-5EF9-45F5-9AF8-127D54801223@seidel.io>
References: <f4de105e96bb0051b576e772726de30fe3bfbcff.camel@joachim-breitner.de>
 <E757BC45-5EF9-45F5-9AF8-127D54801223@seidel.io>
Message-ID: <b02eb94c05bef575817d2e797576bd557df951c0.camel@joachim-breitner.de>

Hi,

sending a proposal back for revision is something you as the shepherd
can just do, without a vote or so. Just explain what’s missing in the
proposal on the github PR, and change the label.

Thanks for shepherding!
Joachim


Am Samstag, dem 02.09.2023 um 20:35 -0400 schrieb Eric Seidel:
> Needs revision. I do think this is a problem worth solving!
> 
> Sent from my iPhone
> 
> > On Sep 2, 2023, at 17:35, Joachim Breitner <mail at joachim-breitner.de> wrote:
> > 
> > Hi,
> > 
> > > Am Samstag, dem 02.09.2023 um 16:05 -0400 schrieb Eric Seidel:
> > > My recommendation is to not accept this proposal in its current form.
> > 
> > is that more a hard reject (i.e. we don't encourage anyone to work on
> > that proposal anymore), or a more a soft “needs revision”?
> > 
> > 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

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


From marlowsd at gmail.com  Sun Sep  3 07:38:35 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Sun, 3 Sep 2023 08:38:35 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
 <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
 <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
Message-ID: <CANsrgP+MY9izKf-ZpO+758TqYNsoUk4gvbjwBmrAxLPJiPKjcg@mail.gmail.com>

On Sun, 3 Sept 2023 at 01:16, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

>
> On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Again, my point is that Unstable extensions should _not_ be in the Stable
>>> ghc releases, and as such anything that's in
>>>
>> the stable ghc releases should be considered stable.
>>>
>>
>> I don't agree with this. To follow your plan we would have to do this:
>>
>>    - Release ghc-9.10
>>    - Release ghc-9.10-experimental
>>    - The two are bit-for-bit identical, except that in ghc-9.10 a bunch
>>    experimental extensions, available in ghc-9.10-experimental, are unavailable
>>
>> I do not consider this significantly more work it’s really just passing
> -DEXPERIMENTAL to the build. But we don’t even need those during our
> _stable_ build releases. We have nighties and we could build nightlies with
> -DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can
> get them through nightly builds.
>

This seems impractical to me. Adding a CPP macro that changes the compiler
doubles the amount of CI and release builds we have to do, and CI for GHC
is barely practical as it is. We discourage the use of CPP for good reasons
- it's much better to use runtime switches.

Cheers
Simon




> This is also what other languages do.
>
> You clearly feel strongly about this so I feel I am missing something
>> important.
>>
>
> Yes, very much so.
>
> Maybe you want -Werror=XExerimental to be the default?  So that to use an
>> experimental feature the user would not only have to invoke it by name, but
>> also switch off the error its use triggers.  That would cause a huge amount
>> of transitional churn which users would hate us for, but I can see some
>> logic in it.
>>
>
> That’s why I’m advocating for a separate build. So they don’t get any
> warning and can enable the features to their heats content. But if you do
> not use the experimental build (e.g. a nightly) you can not, not even by
> accident, enable those features.
>
> By having them in release builds you open the door to lengthy discussions
> of why some features a _stable_ compiler offers should _not_ be used. And
> then have to have reviewers be careful about which extensions and other
> features are enabled or not. It basically puts a lot of work on teams to
> reign in on accidental usage of experimental/unstable features. So then we
> end up building tools on-top, lingers, CI checks to run with
> -Werror=XExerimental, … all just to ensure something which should not be
> there by construction.
>
> I simply do not believe that experimental or unstable features should be
> part of stable releases. What is the definition of stable at that point?
>
> The practice that we put experimental/unstable features into our stable
> releases is something this proposal seems to cement, which is why I’m so
> much against it in this form. I fundamentally believe that if we put
> experimental/unstable features into our releases we must not call them
> stable releases. So we are left with experimental/unstable releases only.
>
> We’ve had discussions around this before:
> - Michael Snoymans Boring Haskell[1]
> - Simple Haskell[2]
> - George Wilson’s talk on Cultivating an Engineering Dialect[3]
>
> I hope this helps clarify my stance on this proposal.
>
> Moritz
>
> —
> [1]:
> https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/
> [2]:
> https://www.simplehaskell.org
> [3]: https://www.youtube.com/watch?v=L4h6VegK1BI
>
>
> On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <moritz.angermann at gmail.com>
>> wrote:
>>
>>> This is a bit hard for me. But here it goes.
>>>
>>> IMO _every_ extension enabled in the public release of GHC _are_ stable
>>> by definition. It's a stable release, thus
>>> the available extensions are also those the GHC team decides to be
>>> stable. While I'm very much in favour of having
>>> a clearer picture of what we currently consider extensions to be. I do
>>> not believe _Unstable_ extensions should
>>> ever be part of a public stable release. I also don't think the
>>> distinction between Legacy and Deprecated is easy to
>>> understand for the end user. Either the extension is supposed to be
>>> used, or not. Stable or Deprecated. The fact that
>>> we'll keep some extension around for what is effectively an infinite
>>> deprecation period is a technicality in my opinion.
>>>
>>> This puts my vote probably fairly square into Alternative 6.3; I don't
>>> think 6.1 is useful. Having to tell people to RTFM
>>> comes across pretty passive aggressive all the time. Also it's the
>>> compiler's knowledge as to what is deprecated or not
>>> and it should report this. 6.2 is even worse, as it now has two
>>> components that need to be kept in sync, while the
>>> extensions are pretty much integral to GHC. Hence GHC has this knowledge
>>> and should report it. 6.4 and 6.5 are in
>>> the same line as the Legacy/Deprecated extra complexity bucket to me.
>>>
>>> Again, what's shipped in the stable release _is_ stable to me. And as
>>> such any _unstable_ extensions should _not_
>>> be in stable ghc releases. Other languages have separate channels for
>>> this. I've also proposed multiple times to have
>>> either two separate development branches: stable + experimental (stable
>>> being periodically merged into experimental),
>>> and cutting _stable_ releases from stable, potentially offering
>>> _experimental_ releases from the experimental branch.
>>> And alternative model is to have a single branch (as I do understand
>>> that getting stuff from the experimental branch
>>> migrated into stable could be a bit messy), but have every _unstable_
>>> extension behind a -DEXPERIMENTAL compile
>>> time flag. The same flag could be used to produce experimental ghc
>>> releases for 3rd parties to consume.
>>>
>>> Again, my point is that Unstable extensions should _not_ be in the
>>> Stable ghc releases, and as such anything that's in
>>> the stable ghc releases should be considered stable. If I want to play
>>> with bleeding edge features, I should have to use
>>> a completely separate compiler for this (again, other languages _do_
>>> follow this approach).
>>>
>>> And that leaves us with stable extensions in GHC, for which we
>>> eventually see that we have better facilities now or
>>> learned over time that these extensions (despite being stable), have
>>> reached their end of life. In that case they should
>>> be marked as deprecated with appropriately long deprecation cycles.
>>>
>>> GHC already has a ton of flags, let's try not to add that many more to
>>> it. Ultimately someone needs to keep all of this
>>> in their head, while also trying to get their job done. And for some
>>> this job is 9-5, five days a week only; no late night
>>> hacking sessions, no weekend projects; but instead soccer
>>> practice, cycling, spending time with their family. If we want
>>> to make haskell successful, we need to make sure that in that people can
>>> be effective and productive and solve real
>>> world problems in the 40hs they have per week; and not study manuals, or
>>> flags (and if they see one of the many
>>> unknown flags, go study those flags) more than absolutely necessary to
>>> get work done.
>>>
>>> In summary, I don't see myself supporting this proposal as it adds too
>>> much complexity and sets in stone that unstable
>>> extensions are part of a stable compiler. I'm happy to see that the
>>> "only deprecations" option is listed as an alternative
>>> in 6.3, even though I do not agree with the assessment that we need more
>>> nuance for users. Extension in my opinion
>>> should only be stable, or deprecated. And the end user should never see
>>> unstable extensions, unless they _explicitly_
>>> asked for an experimental/unstable compiler.
>>>
>>> Moritz
>>>
>>> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:
>>>
>>>> There's a non-normative and a normative component to this proposal.
>>>>
>>>> The non-normative piece says that there should be a categorization
>>>> scheme for language extensions. That is inarguable in my opinion. The
>>>> proposal also suggests an initial framework of four categories, which seems
>>>> like a reasonable place to start. (Vlad says we should first figure out how
>>>> to map all extensions to the categories; I disagree. We can iterate on the
>>>> categories over time, as needed.)
>>>>
>>>> The normative piece of the proposal says that we should start warning
>>>> on the use of any Deprecated, Unstable, or Legacy extensions. This seems
>>>> like a reasonable ideal, but the practicality kind of hinges on the
>>>> bucketing of specific extensions (and on Richard's question of how
>>>> `default-language` is interpreted). The authors give some recommendations
>>>> of how to bucket particular extensions, but it's not exhaustive and I also
>>>> view it as the authors' desire rather than a specific commitment of the
>>>> proposal.
>>>>
>>>> So in my view:
>>>>
>>>> * Yes, we should have a framework for categorizing the jungle of
>>>> language extensions, and the proposal seems like a fine starting point.
>>>> * Yes, we should have a set of warnings for users who would like to
>>>> forbid certain categories of extensions.
>>>> * We should probably defer any decisions about default enablement of
>>>> warnings until we have a complete proposed categorization. And that
>>>> discussion should include some analysis of the pervasiveness of
>>>> "deprecated", "unstable", and "legacy" extensions so we can judge the
>>>> amount of churn. Just like any other discussion about deprecation.
>>>>
>>>> Eric
>>>>
>>>> On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>>>> > I've just posted on the GitHub ticket. I remain against the proposal
>>>> in
>>>> > its current form, mostly because it means (if I understand correctly)
>>>> > that everyone who says `default-language: Haskell2010` will get
>>>> > warnings.
>>>> >
>>>> > Richard
>>>> >
>>>> >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com>
>>>> wrote:
>>>> >>
>>>> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com>
>>>> wrote:
>>>> >>> A few things make this not a straightforward thumbs up for me,
>>>> though I'm not strongly against.
>>>> >>>
>>>> >>> What is the interaction with GHC20xx? Presumably we want to say
>>>> something like GHC20xx will never include any Deprecated or Legacy
>>>> extensions? What about Unsable? if an extension transitions from Stable ->
>>>> Legacy, would we remove it from the next GHC20xx?
>>>> >>
>>>> >> Ah, I just noticed that the proposal does say something about this:
>>>> >>
>>>> >>> For existing, or future, language sets such as `GHC2021` or
>>>> `Haskell98`, it is expected that none of the contained extensions would be
>>>> `Unstable`. However, this proposal does not seek to impose any particular
>>>> policy on the inclusion of extensions into language sets - the developers
>>>> and the steering committee are always in the best position to make a
>>>> decision about a concrete extension and extension set.
>>>> >>
>>>> >> OK.
>>>> >>
>>>> >> Simon
>>>> >>
>>>> >>
>>>> >>>
>>>> >>> Something doesn't feel quite right about the warning system. If a
>>>> module can start with
>>>> >>>
>>>> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>>> >>> {-# LANGUAGE OverlappingInstances #-}
>>>> >>>
>>>> >>> and silently use an extension that the {build system, user,
>>>> project} wanted to disallow, have we achieved anything? Compare this to the
>>>> current situation, where the environment can say -XNoOverlappingInstances
>>>> and code can override that with {-# LANGUAGE OverlappingInstances #-} -
>>>> there's essentially no difference, we just added another layer of
>>>> disable/override that isn't buying us anything.
>>>> >>>
>>>> >>> (note I'm viewing this through the spectacles of -Werror, because
>>>> I've come to believe that warnings are essentially not useful unless given
>>>> teeth with -Werror.)
>>>> >>>
>>>> >>> Cheers
>>>> >>> Simon
>>>> >>>
>>>> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <
>>>> vlad.z.4096 at gmail.com> wrote:
>>>> >>>> I agree that we need a categorisation of extension language flags,
>>>> but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is the
>>>> right set of labels. In fact, I wouldn't want to commit to any particular
>>>> categorisation before we actually go through all the extensions in GHC and
>>>> see for ourselves that they can be adequately categorized according to the
>>>> proposed system.
>>>> >>>>
>>>> >>>> The proposal says "classifications of individual language
>>>> extensions will be left to a future proposal". Well, I am skeptical that
>>>> this separation makes sense. I would much prefer if we were discussing a
>>>> concrete categorisation proposal, not just a set of four labels whose
>>>> implications I can't fully grasp.
>>>> >>>>
>>>> >>>> Vlad
>>>> >>>>
>>>> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>> >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>>> >>>>>
>>>> >>>>> I would love to hear from you about this proposal.  *Please*.
>>>> >>>>>
>>>> >>>>> I plan to accept it unless I hear dissent.  But I would much
>>>> rather have an explicit response from you than take silence as assent.  You
>>>> are a member of the committee, after all!
>>>> >>>>>
>>>> >>>>> My apologies if I have missed your reply
>>>> >>>>>
>>>> >>>>> Simon
>>>> >> _______________________________________________
>>>> >> 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/20230903/9b94925b/attachment-0001.html>

From moritz.angermann at gmail.com  Sun Sep  3 08:10:31 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 3 Sep 2023 16:10:31 +0800
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CANsrgP+MY9izKf-ZpO+758TqYNsoUk4gvbjwBmrAxLPJiPKjcg@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
 <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
 <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
 <CANsrgP+MY9izKf-ZpO+758TqYNsoUk4gvbjwBmrAxLPJiPKjcg@mail.gmail.com>
Message-ID: <CAKfdd-xw5xxGo1fNnCE7NUPjKA1gQK3fm0mFiX=y=oSN91MB+w@mail.gmail.com>

How about —std=experimental then, if it needs to be a runtime flag due to
CI constraints?
Whether or not that flag is only exposed for nightly builds and not for
release builds is another option.
That should help with the CPP mess and CI load?

On Sun, 3 Sep 2023 at 3:38 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> On Sun, 3 Sept 2023 at 01:16, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>>
>> On Sat, 2 Sep 2023 at 9:56 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Again, my point is that Unstable extensions should _not_ be in the
>>>> Stable ghc releases, and as such anything that's in
>>>>
>>> the stable ghc releases should be considered stable.
>>>>
>>>
>>> I don't agree with this. To follow your plan we would have to do this:
>>>
>>>    - Release ghc-9.10
>>>    - Release ghc-9.10-experimental
>>>    - The two are bit-for-bit identical, except that in ghc-9.10 a bunch
>>>    experimental extensions, available in ghc-9.10-experimental, are unavailable
>>>
>>> I do not consider this significantly more work it’s really just passing
>> -DEXPERIMENTAL to the build. But we don’t even need those during our
>> _stable_ build releases. We have nighties and we could build nightlies with
>> -DEXPERIMENTAL. Thus everyone who wants unstable/experimental features can
>> get them through nightly builds.
>>
>
> This seems impractical to me. Adding a CPP macro that changes the compiler
> doubles the amount of CI and release builds we have to do, and CI for GHC
> is barely practical as it is. We discourage the use of CPP for good reasons
> - it's much better to use runtime switches.
>
> Cheers
> Simon
>
>
>
>
>> This is also what other languages do.
>>
>> You clearly feel strongly about this so I feel I am missing something
>>> important.
>>>
>>
>> Yes, very much so.
>>
>> Maybe you want -Werror=XExerimental to be the default?  So that to use an
>>> experimental feature the user would not only have to invoke it by name, but
>>> also switch off the error its use triggers.  That would cause a huge amount
>>> of transitional churn which users would hate us for, but I can see some
>>> logic in it.
>>>
>>
>> That’s why I’m advocating for a separate build. So they don’t get any
>> warning and can enable the features to their heats content. But if you do
>> not use the experimental build (e.g. a nightly) you can not, not even by
>> accident, enable those features.
>>
>> By having them in release builds you open the door to lengthy discussions
>> of why some features a _stable_ compiler offers should _not_ be used. And
>> then have to have reviewers be careful about which extensions and other
>> features are enabled or not. It basically puts a lot of work on teams to
>> reign in on accidental usage of experimental/unstable features. So then we
>> end up building tools on-top, lingers, CI checks to run with
>> -Werror=XExerimental, … all just to ensure something which should not be
>> there by construction.
>>
>> I simply do not believe that experimental or unstable features should be
>> part of stable releases. What is the definition of stable at that point?
>>
>> The practice that we put experimental/unstable features into our stable
>> releases is something this proposal seems to cement, which is why I’m so
>> much against it in this form. I fundamentally believe that if we put
>> experimental/unstable features into our releases we must not call them
>> stable releases. So we are left with experimental/unstable releases only.
>>
>> We’ve had discussions around this before:
>> - Michael Snoymans Boring Haskell[1]
>> - Simple Haskell[2]
>> - George Wilson’s talk on Cultivating an Engineering Dialect[3]
>>
>> I hope this helps clarify my stance on this proposal.
>>
>> Moritz
>>
>> —
>> [1]:
>> https://www.snoyman.com/blog/2019/11/boring-haskell-manifesto/
>> [2]:
>> https://www.simplehaskell.org
>> [3]: https://www.youtube.com/watch?v=L4h6VegK1BI
>>
>>
>> On Sat, 2 Sept 2023 at 03:49, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> This is a bit hard for me. But here it goes.
>>>>
>>>> IMO _every_ extension enabled in the public release of GHC _are_ stable
>>>> by definition. It's a stable release, thus
>>>> the available extensions are also those the GHC team decides to be
>>>> stable. While I'm very much in favour of having
>>>> a clearer picture of what we currently consider extensions to be. I do
>>>> not believe _Unstable_ extensions should
>>>> ever be part of a public stable release. I also don't think the
>>>> distinction between Legacy and Deprecated is easy to
>>>> understand for the end user. Either the extension is supposed to be
>>>> used, or not. Stable or Deprecated. The fact that
>>>> we'll keep some extension around for what is effectively an infinite
>>>> deprecation period is a technicality in my opinion.
>>>>
>>>> This puts my vote probably fairly square into Alternative 6.3; I don't
>>>> think 6.1 is useful. Having to tell people to RTFM
>>>> comes across pretty passive aggressive all the time. Also it's the
>>>> compiler's knowledge as to what is deprecated or not
>>>> and it should report this. 6.2 is even worse, as it now has two
>>>> components that need to be kept in sync, while the
>>>> extensions are pretty much integral to GHC. Hence GHC has this
>>>> knowledge and should report it. 6.4 and 6.5 are in
>>>> the same line as the Legacy/Deprecated extra complexity bucket to me.
>>>>
>>>> Again, what's shipped in the stable release _is_ stable to me. And as
>>>> such any _unstable_ extensions should _not_
>>>> be in stable ghc releases. Other languages have separate channels for
>>>> this. I've also proposed multiple times to have
>>>> either two separate development branches: stable + experimental (stable
>>>> being periodically merged into experimental),
>>>> and cutting _stable_ releases from stable, potentially offering
>>>> _experimental_ releases from the experimental branch.
>>>> And alternative model is to have a single branch (as I do understand
>>>> that getting stuff from the experimental branch
>>>> migrated into stable could be a bit messy), but have every _unstable_
>>>> extension behind a -DEXPERIMENTAL compile
>>>> time flag. The same flag could be used to produce experimental ghc
>>>> releases for 3rd parties to consume.
>>>>
>>>> Again, my point is that Unstable extensions should _not_ be in the
>>>> Stable ghc releases, and as such anything that's in
>>>> the stable ghc releases should be considered stable. If I want to play
>>>> with bleeding edge features, I should have to use
>>>> a completely separate compiler for this (again, other languages _do_
>>>> follow this approach).
>>>>
>>>> And that leaves us with stable extensions in GHC, for which we
>>>> eventually see that we have better facilities now or
>>>> learned over time that these extensions (despite being stable), have
>>>> reached their end of life. In that case they should
>>>> be marked as deprecated with appropriately long deprecation cycles.
>>>>
>>>> GHC already has a ton of flags, let's try not to add that many more to
>>>> it. Ultimately someone needs to keep all of this
>>>> in their head, while also trying to get their job done. And for some
>>>> this job is 9-5, five days a week only; no late night
>>>> hacking sessions, no weekend projects; but instead soccer
>>>> practice, cycling, spending time with their family. If we want
>>>> to make haskell successful, we need to make sure that in that people
>>>> can be effective and productive and solve real
>>>> world problems in the 40hs they have per week; and not study manuals,
>>>> or flags (and if they see one of the many
>>>> unknown flags, go study those flags) more than absolutely necessary to
>>>> get work done.
>>>>
>>>> In summary, I don't see myself supporting this proposal as it adds too
>>>> much complexity and sets in stone that unstable
>>>> extensions are part of a stable compiler. I'm happy to see that the
>>>> "only deprecations" option is listed as an alternative
>>>> in 6.3, even though I do not agree with the assessment that we need
>>>> more nuance for users. Extension in my opinion
>>>> should only be stable, or deprecated. And the end user should never see
>>>> unstable extensions, unless they _explicitly_
>>>> asked for an experimental/unstable compiler.
>>>>
>>>> Moritz
>>>>
>>>> On Sat, 2 Sept 2023 at 08:24, Eric Seidel <eric at seidel.io> wrote:
>>>>
>>>>> There's a non-normative and a normative component to this proposal.
>>>>>
>>>>> The non-normative piece says that there should be a categorization
>>>>> scheme for language extensions. That is inarguable in my opinion. The
>>>>> proposal also suggests an initial framework of four categories, which seems
>>>>> like a reasonable place to start. (Vlad says we should first figure out how
>>>>> to map all extensions to the categories; I disagree. We can iterate on the
>>>>> categories over time, as needed.)
>>>>>
>>>>> The normative piece of the proposal says that we should start warning
>>>>> on the use of any Deprecated, Unstable, or Legacy extensions. This seems
>>>>> like a reasonable ideal, but the practicality kind of hinges on the
>>>>> bucketing of specific extensions (and on Richard's question of how
>>>>> `default-language` is interpreted). The authors give some recommendations
>>>>> of how to bucket particular extensions, but it's not exhaustive and I also
>>>>> view it as the authors' desire rather than a specific commitment of the
>>>>> proposal.
>>>>>
>>>>> So in my view:
>>>>>
>>>>> * Yes, we should have a framework for categorizing the jungle of
>>>>> language extensions, and the proposal seems like a fine starting point.
>>>>> * Yes, we should have a set of warnings for users who would like to
>>>>> forbid certain categories of extensions.
>>>>> * We should probably defer any decisions about default enablement of
>>>>> warnings until we have a complete proposed categorization. And that
>>>>> discussion should include some analysis of the pervasiveness of
>>>>> "deprecated", "unstable", and "legacy" extensions so we can judge the
>>>>> amount of churn. Just like any other discussion about deprecation.
>>>>>
>>>>> Eric
>>>>>
>>>>> On Fri, Sep 1, 2023, at 12:56, Richard Eisenberg wrote:
>>>>> > I've just posted on the GitHub ticket. I remain against the proposal
>>>>> in
>>>>> > its current form, mostly because it means (if I understand
>>>>> correctly)
>>>>> > that everyone who says `default-language: Haskell2010` will get
>>>>> > warnings.
>>>>> >
>>>>> > Richard
>>>>> >
>>>>> >> On Sep 1, 2023, at 12:21 PM, Simon Marlow <marlowsd at gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> On Fri, 1 Sept 2023 at 17:17, Simon Marlow <marlowsd at gmail.com>
>>>>> wrote:
>>>>> >>> A few things make this not a straightforward thumbs up for me,
>>>>> though I'm not strongly against.
>>>>> >>>
>>>>> >>> What is the interaction with GHC20xx? Presumably we want to say
>>>>> something like GHC20xx will never include any Deprecated or Legacy
>>>>> extensions? What about Unsable? if an extension transitions from Stable ->
>>>>> Legacy, would we remove it from the next GHC20xx?
>>>>> >>
>>>>> >> Ah, I just noticed that the proposal does say something about this:
>>>>> >>
>>>>> >>> For existing, or future, language sets such as `GHC2021` or
>>>>> `Haskell98`, it is expected that none of the contained extensions would be
>>>>> `Unstable`. However, this proposal does not seek to impose any particular
>>>>> policy on the inclusion of extensions into language sets - the developers
>>>>> and the steering committee are always in the best position to make a
>>>>> decision about a concrete extension and extension set.
>>>>> >>
>>>>> >> OK.
>>>>> >>
>>>>> >> Simon
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> Something doesn't feel quite right about the warning system. If a
>>>>> module can start with
>>>>> >>>
>>>>> >>> {-# OPTIONS_GHC -Wno-XDeprecated #-}
>>>>> >>> {-# LANGUAGE OverlappingInstances #-}
>>>>> >>>
>>>>> >>> and silently use an extension that the {build system, user,
>>>>> project} wanted to disallow, have we achieved anything? Compare this to the
>>>>> current situation, where the environment can say -XNoOverlappingInstances
>>>>> and code can override that with {-# LANGUAGE OverlappingInstances #-} -
>>>>> there's essentially no difference, we just added another layer of
>>>>> disable/override that isn't buying us anything.
>>>>> >>>
>>>>> >>> (note I'm viewing this through the spectacles of -Werror, because
>>>>> I've come to believe that warnings are essentially not useful unless given
>>>>> teeth with -Werror.)
>>>>> >>>
>>>>> >>> Cheers
>>>>> >>> Simon
>>>>> >>>
>>>>> >>> On Fri, 1 Sept 2023 at 13:18, Vladislav Zavialov <
>>>>> vlad.z.4096 at gmail.com> wrote:
>>>>> >>>> I agree that we need a categorisation of extension language
>>>>> flags, but I'm not convinced that {Stable, Unstable, Deprecated, Legacy} is
>>>>> the right set of labels. In fact, I wouldn't want to commit to any
>>>>> particular categorisation before we actually go through all the extensions
>>>>> in GHC and see for ourselves that they can be adequately categorized
>>>>> according to the proposed system.
>>>>> >>>>
>>>>> >>>> The proposal says "classifications of individual language
>>>>> extensions will be left to a future proposal". Well, I am skeptical that
>>>>> this separation makes sense. I would much prefer if we were discussing a
>>>>> concrete categorisation proposal, not just a set of four labels whose
>>>>> implications I can't fully grasp.
>>>>> >>>>
>>>>> >>>> Vlad
>>>>> >>>>
>>>>> >>>> On Fri, Sep 1, 2023 at 11:37 AM Simon Peyton Jones <
>>>>> simon.peytonjones at gmail.com> wrote:
>>>>> >>>>> Dear Simon, Vlad, Eric, Chris, Moritz
>>>>> >>>>>
>>>>> >>>>> I would love to hear from you about this proposal.  *Please*.
>>>>> >>>>>
>>>>> >>>>> I plan to accept it unless I hear dissent.  But I would much
>>>>> rather have an explicit response from you than take silence as assent.  You
>>>>> are a member of the committee, after all!
>>>>> >>>>>
>>>>> >>>>> My apologies if I have missed your reply
>>>>> >>>>>
>>>>> >>>>> Simon
>>>>> >> _______________________________________________
>>>>> >> 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/20230903/894cb8f1/attachment-0001.html>

From adam at well-typed.com  Sun Sep  3 08:59:02 2023
From: adam at well-typed.com (Adam Gundry)
Date: Sun, 3 Sep 2023 09:59:02 +0100
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
 <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
 <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
Message-ID: <80997042-06ec-3785-b4d4-bc9912751366@well-typed.com>

On 03/09/2023 01:15, Moritz Angermann wrote:
> 
> The practice that we put experimental/unstable features into our stable 
> releases is something this proposal seems to cement, which is why I’m so 
> much against it in this form.

But that practice is already firmly established (de facto), it's not 
something being introduced by this proposal! So while I understand your 
opposition to *the practice*, I'm struggling to understand the strength 
of your opposition to *the proposal*.

You're welcome to make the argument (in a subsequent proposal, perhaps) 
that GHC should more firmly gate access to unstable features. If 
anything, that would seem easier to specify once the proposal's approach 
clearly defines those features. And in the interim, at least the 
proposal makes it possible to switch off unstable features systematically.

So I understand that this proposal doesn't get you everything you want. 
But it seems like a reasonable interim step, and one that is more likely 
to command broad consensus than a radical change to release practices?

Best wishes,

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From moritz.angermann at gmail.com  Sun Sep  3 09:50:25 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 3 Sep 2023 17:50:25 +0800
Subject: [ghc-steering-committee] Urgent: exension life cycle proposal
In-Reply-To: <80997042-06ec-3785-b4d4-bc9912751366@well-typed.com>
References: <1357869695964d4f88703711ca1efbe9e611d252.camel@joachim-breitner.de>
 <CAJKmMz9R0pbuZxFeNdWb+v4bF7vgoUF8AKZcVQ6DPNTat+hc+A@mail.gmail.com>
 <CAJKmMz_hP1M9LmVaboxQN7bOUH5qYDFQfZ1if6Gf6uVy-CdWeg@mail.gmail.com>
 <CAJKmMz-4PYfKj=wpT-tAseynEFv4Uktd6Pnvpk9ReUz+0fCrrA@mail.gmail.com>
 <CAHZ0NLrX+5S+4G63yiHsFbB9m+78y8LaXE7433AhLitzdniNcg@mail.gmail.com>
 <CANsrgPJ_7Yiuwc71TUgEYU1K4hos3o_sr0A5UgovZt7_1-CfXg@mail.gmail.com>
 <CANsrgPLdkUJ1wcb5Fa1ZdmFTwmb1-ohaWR-SRSDK+2GVnVjUxw@mail.gmail.com>
 <010f018a51ad1fe9-ed6fef5e-fa3a-4447-b2fe-d60877e80233-000000@us-east-2.amazonses.com>
 <ce6c26f8-d00e-4aa3-98d8-0e27b000fa9c@app.fastmail.com>
 <CAKfdd-xaUiM5kBuTBTH-gADDUX4W5XWFFEWn-2CQU-0yEWH4jg@mail.gmail.com>
 <CAJKmMz9WpQ1kD_jnM28nVGOOV3UmFhptzxD2n2UcQ28iXPO8bA@mail.gmail.com>
 <CAKfdd-wxy1wZPgrAYJmHiashRY0Ys-+GQKCPiRhKMbn9AGOGaA@mail.gmail.com>
 <80997042-06ec-3785-b4d4-bc9912751366@well-typed.com>
Message-ID: <CAKfdd-xbZ7T4UBErtwVixfmN1wto+aFwRSZvuTZtv_A4urrTZQ@mail.gmail.com>

Adam,

How can I support a proposal that cements a
already firmly established practice, I fundamentally disagree with?

Every extension in a stable GHC release by extension has to be stable,
maybe deprecated. But stable. This proposal basically says it is ok to have
unstable extensions in a stable GHC release. I do not believe that
-WXUnstable should exist in a stable compiler. And from an end user
perspective I think there can only be stable and deprecated extensions.

GHC is already a highly complex piece of software from an end user
perspective, let’s try to make it simpler not add even more complexity.

I have no intentions to turn this proposal into
a radical change to release practices. I have provided most of this for
context as to why I can not see myself supporting this proposal as is.

I can support a subset of the proposal. I do not see how I can support a
this proposal in its entirety?

Best,
  Moritz

On Sun, 3 Sep 2023 at 4:59 PM, Adam Gundry <adam at well-typed.com> wrote:

> On 03/09/2023 01:15, Moritz Angermann wrote:
> >
> > The practice that we put experimental/unstable features into our stable
> > releases is something this proposal seems to cement, which is why I’m so
> > much against it in this form.
>
> But that practice is already firmly established (de facto), it's not
> something being introduced by this proposal! So while I understand your
> opposition to *the practice*, I'm struggling to understand the strength
> of your opposition to *the proposal*.
>
> You're welcome to make the argument (in a subsequent proposal, perhaps)
> that GHC should more firmly gate access to unstable features. If
> anything, that would seem easier to specify once the proposal's approach
> clearly defines those features. And in the interim, at least the
> proposal makes it possible to switch off unstable features systematically.
>
> So I understand that this proposal doesn't get you everything you want.
> But it seems like a reasonable interim step, and one that is more likely
> to command broad consensus than a radical change to release practices?
>
> Best wishes,
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230903/7c71b23f/attachment.html>

From chris at chrisdornan.com  Mon Sep  4 04:43:43 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 4 Sep 2023 05:43:43 +0100
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>
References: <a0ae2adcaccda9d75fe867a73855118b7658583b.camel@joachim-breitner.de>
Message-ID: <0F56D81C-CB73-4785-9145-411BC98360E9@chrisdornan.com>

Thanks again Joachim and Simon,

I have reviewed #434 and #509 and am preparing recommendations -- I have given feedback in the thread accordingly and expect to be emailing y'all with my recommendations later this week.

Chris

> On 2 Sep 2023, at 09:09, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> time for another status email, in particular because I need an up-to-date
> update to get stats for Simon’s famous report at HIW on Monday. Hope to see
> some of you there! Let’s see what has happened since July 3
> 
> * Arnaud did round 3 of his language extension policy investigation. 
> 
> * we were asked to review these proposals:
> 
>   #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, Sepherd: Joachim
>   #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>   #583: HasField redesign, Shepherd: Arnaud
>   #609: (p1; p2) for or-patterns, Shepherd: Chris
>   #607: Amendments clarify treatment of term variables in types, Shepherd: Vlad
>   #605: visible forall to work without ScopedTypeVariables, Shepherd: Joachim
>   #601: Extension lifecycle, Shepherd: Simon PJ
> 
> * we have a recommendation from the shepherd about:
> 
>   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept
>   #605: visible forall to work without ScopedTypeVariables, rec: accept
>   #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
>   #583: HasField redesign, rec: accept
>   #601: Extension lifecycle, rec: accept
> 
> * we have sent the following proposals back to revision
> 
>   #601: Extension lifecycle
> 
> * we decided about the following proposals
> 
>   #596: sized literals in Show, accept
>   #581: Namespaces-specified Imports, accept
>   #604: do not let -XScopedTypeVariables imply -XTypeAbstractions, accept
>   #607: Amend #281 (visible forall) and #378 (Design of DH) to clarify treatment of term variables in types (rec: accept)
>   #605: visible forall to work without ScopedTypeVariables, accept
> 
> So we currently have to act on the following 9 proposals, up one since
> last time:
> 
> ## Waiting for committee decision
> 
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>      2022-09-03: Assigned to Baldur
>      2022-10-02: Reassignd to Vlad
>      2022-11-30: Vlad recommends rejection
>      This needs to be picked up again, it has been lingering too long!
> 
> #536: Type-level literals as a sep language extension, Shepherd: Vlad
>      2023-02-16 Assigned to Vlad
>      2023-03-06 Vlad recommends acceptance
>      Some hesitancy in the committee to introduce this extension,
>      the ongoing policy clarification process might guide us, 
>      but maybe we can resolve this earlier?
> 
> #583: HasField redesign, rec: accept
>      2023-08-30 Arnaud recommends acceptance
> 
> ## Waiting for shepherd recommendation
> 
> #526: Applicative Comprehensions, Shepherd: Simon M
>      2022-10-08: Assigned to Simon M
>      Simon, please cast your recommendation!
> 
> #585: Amend Or Patterns, Shepherd: Richard
>      2023-04-11: Assigned to Richard
>      There are votes on syntax going on, ran by Sebastian Graf.
>      Maybe this should be in “needs revision” until they are through.
>      Richard, I’ll leave this to you
> #609 seems to be related, not sure if we need both.
> 
> #194: Updated partial type signatures, Shepherd: Eric
>      2023-05-25: Came back from needs revision
> 
> #434: Fine-grained unused warnings, Shepherd: Chris
>      2023-07-02: Assigned to Chris
> 
> #597: Constraints synonyms in deriving heads, Shepherd: Moritz
>      2023-07-25: Assigned to Moritz
> 
> #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
>      2023-08-17: Assigned to Richard
> 
> 
> 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 arnaud.spiwack at tweag.io  Wed Sep  6 14:27:13 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 6 Sep 2023 16:27:13 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
Message-ID: <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>

Dear all,

Don't forget to opine here. To reiterate, I really don't expect the
proposal to be controversial. The text of the proposal is rather long, but
is made easy to read. So it shouldn't take too much of your time.

/Arnaud

On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I support acceptance.
>
> Simon
>
> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>>
>> Our own Adam proposes to amend the design of the highly experimental
>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>>
>> Specifically, Adam proposes a modification of the type classes that would
>> back the extension.
>>
>> In the previous design the HasField class is defined as a lens:
>>
>> class HasField (n :: k) r a | r n -> a
>>   hasField :: r -> (a -> r, a)
>>
>> The proposal is to replace it by two classes (slightly simplified)
>>
>> class HasField (n :: k) r a | r n -> a
>>   hasField :: r -> a
>>
>> class SetField (n::k) r a | r n -> a
>>   modifyField :: (a -> a) -> r -> a
>>   setField :: a -> r -> a
>>
>> This is originally motivated by some performance consideration: the
>> prototype implementation of HasField as a lens can be very time consuming
>> because instances of HasFields are generated eagerly at record definition
>> sites, whereas the simple HasField instances can simply reuse the selectors
>> already generated by GHC. But a lot of thoughts have been put into the new
>> design, and my summary can certainly not do it justice: the proposal is
>> very well argumented.
>>
>> A point I'll make here is that the new design is actually parametric in
>> the data representation of the field type. Something that wasn't possible
>> in the original design.
>>
>> This proposal is not technically backward compatible, because the order
>> of argument in which OverloadedRecordUpdate expects the argument of
>> setField is changed. This is not essential to the proposal, but this is a
>> more consistent order argument with the rest of Haskell. And considering
>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>> recommend accepting this breakage.
>>
>> Overall the proposal is actually more backward compatible with GHC 9.8
>> than the original design, as the HasField class is left unchanged.
>>
>> Overall, the proposal looks quite reasonable to me, and well-argued. I
>> recommend acceptance.
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230906/a5646304/attachment.html>

From chris at chrisdornan.com  Fri Sep  8 10:15:52 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 8 Sep 2023 11:15:52 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
Message-ID: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>

Proposal: Fine-Grained Unused Warnings (#42)
Author: Jakob Brünker
Rendered proposal:
https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
Recommendation: Acceptance

## Summary

GHC currently warns equally about any superfluous binding that it
discovers, regardless of whether
the definition is unreferenced anywhere itself, or is merely mentioned by
other definitions that are
similarly superfluous. The proposal proposes to replace these warnings with
just the warnings about
definitions that are not referenced anywhere, but list within those
warnings the entities it
references that would otherwise not be required. The same information is
being conveyed under this
proposal as previously, but in a more structured manner.

The proposal is careful to ensure the -Wunused-* controls
(-Wunused-top-binds, etc.) are respected,
so the subwarnings of transitively unused entities are only listed if their
corresponding -Wunused-*
control is active.

As Jakob points out in the proposal, getting these warnings into some
structure is partly motivated
by IDE usage where the 'additional [transitive] warnings take up a lot of
valuable screen real
estate'.

## Example [From the proposal]

In the following code,

module Foo ()

import Data.List as L

foo = L.intercalate

`intercalate` is transitively unused, since it is only used by `foo`, which
is unused. The warning
that's produced will be

Foo.hs:5:1: warning: [-Wunused-top-binds]
Defined but not used: ‘foo’
as a consequence the following imports are transitively unused
[-Wunused-imports]:
Data.List imported at foo.hs:3:1:

The warning about transitively unused bindings only appears if both the
warning flag for the unused binding (in this case -Wunused-top-binds) and
the the one for the transitively unused binding itself (in this case
-Wunused-imports) are enabled.


## Recommendation

This proposal is not at all disruptive (arguably to the extent of not
requiring a GHC proposal
review), is well thought out, and can improve the GHC/IDE UI so I recommend
that we accept it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230908/68234efa/attachment.html>

From chris at chrisdornan.com  Fri Sep  8 10:57:25 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 8 Sep 2023 11:57:25 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
Message-ID: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>

Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
Author: Sebastian Graf, David Knothe
Rendered proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
Recommendation: Acceptance

## Summary

This proposal refines the syntax of an already accpted proposal (#522) for
writing or patterns.

The syntax of the old proposal,

```haskell
stringOfT :: T -> Maybe String
stringOfT (T1 s) = Just s
stringOfT (one of T2{}, T3{}) = Nothing
```

is replaced with

```haskell
stringOfT :: T -> Maybe String
stringOfT (T1 s) = Just s
stringOfT (T2{}; T3{}) = Nothing
```

or indeed

```haskell
stringOfT :: T -> Maybe String
stringOfT x = case x of
T1 s -> Just s
T2{}
T3{} -> Nothing
```

(Beacuse the '(' ... ')' are optional here, we can remove them and
naturally exploit layout.)

The authors have conducted polls to see what folks preferred, landing on
this proposal. The
adjustments to the Haskell grammar are really quite minimal requiring one
extra production.

## Recommendation

The proposal is nondiruptive and as a whole addresses an important
practical topic. I recommend
that we accept it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230908/bb84003c/attachment.html>

From simon.peytonjones at gmail.com  Fri Sep  8 16:36:14 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 8 Sep 2023 09:36:14 -0700
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
Message-ID: <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>

I don't have a strong opinion here.   The authors have done a pretty
diligent job of exploring syntactic alternatives, and seeking feedback from
the community.  I'm quite content to accept this proposal.  (We have
already accepted the base or-pattern proposal, so that's not our subject
for debate.)

Simon

On Fri, 8 Sept 2023 at 03:57, Chris Dornan <chris at chrisdornan.com> wrote:

> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> Author: Sebastian Graf, David Knothe
> Rendered proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> Recommendation: Acceptance
>
> ## Summary
>
> This proposal refines the syntax of an already accpted proposal (#522) for
> writing or patterns.
>
> The syntax of the old proposal,
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (one of T2{}, T3{}) = Nothing
> ```
>
> is replaced with
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (T2{}; T3{}) = Nothing
> ```
>
> or indeed
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT x = case x of
> T1 s -> Just s
> T2{}
> T3{} -> Nothing
> ```
>
> (Beacuse the '(' ... ')' are optional here, we can remove them and
> naturally exploit layout.)
>
> The authors have conducted polls to see what folks preferred, landing on
> this proposal. The
> adjustments to the Haskell grammar are really quite minimal requiring one
> extra production.
>
> ## Recommendation
>
> The proposal is nondiruptive and as a whole addresses an important
> practical topic. I recommend
> that we accept it
>
> _______________________________________________
> 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/20230908/1f29bf2d/attachment.html>

From vlad.z.4096 at gmail.com  Fri Sep  8 17:47:02 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Fri, 8 Sep 2023 19:47:02 +0200
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
Message-ID: <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>

In favor

On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I don't have a strong opinion here.   The authors have done a pretty
> diligent job of exploring syntactic alternatives, and seeking feedback from
> the community.  I'm quite content to accept this proposal.  (We have
> already accepted the base or-pattern proposal, so that's not our subject
> for debate.)
>
> Simon
>
> On Fri, 8 Sept 2023 at 03:57, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
>> Author: Sebastian Graf, David Knothe
>> Rendered proposal:
>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
>> Recommendation: Acceptance
>>
>> ## Summary
>>
>> This proposal refines the syntax of an already accpted proposal (#522)
>> for writing or patterns.
>>
>> The syntax of the old proposal,
>>
>> ```haskell
>> stringOfT :: T -> Maybe String
>> stringOfT (T1 s) = Just s
>> stringOfT (one of T2{}, T3{}) = Nothing
>> ```
>>
>> is replaced with
>>
>> ```haskell
>> stringOfT :: T -> Maybe String
>> stringOfT (T1 s) = Just s
>> stringOfT (T2{}; T3{}) = Nothing
>> ```
>>
>> or indeed
>>
>> ```haskell
>> stringOfT :: T -> Maybe String
>> stringOfT x = case x of
>> T1 s -> Just s
>> T2{}
>> T3{} -> Nothing
>> ```
>>
>> (Beacuse the '(' ... ')' are optional here, we can remove them and
>> naturally exploit layout.)
>>
>> The authors have conducted polls to see what folks preferred, landing on
>> this proposal. The
>> adjustments to the Haskell grammar are really quite minimal requiring one
>> extra production.
>>
>> ## Recommendation
>>
>> The proposal is nondiruptive and as a whole addresses an important
>> practical topic. I recommend
>> that we accept it
>>
>> _______________________________________________
>> 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/20230908/83c4db50/attachment.html>

From adam at well-typed.com  Fri Sep  8 19:58:24 2023
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 8 Sep 2023 20:58:24 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
Message-ID: <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>

No objections from me. I tend not to pay too much attention to such 
syntactic niceties, but as the authors have gone to the trouble of 
surveying the community and implementing the proposal I see no reason 
not to accept their suggested syntax.

I did notice that the PR drops Ömer's name from the authors list for 
#522, I'm not sure if that was intentional?

Adam


On 08/09/2023 18:47, Vladislav Zavialov wrote:
> In favor
> 
> On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones 
> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>     I don't have a strong opinion here.   The authors have done a pretty
>     diligent job of exploring syntactic alternatives, and seeking
>     feedback from the community.  I'm quite content to accept this
>     proposal.  (We have already accepted the base or-pattern proposal,
>     so that's not our subject for debate.)
> 
>     Simon
> 
>     On Fri, 8 Sept 2023 at 03:57, Chris Dornan <chris at chrisdornan.com
>     <mailto:chris at chrisdornan.com>> wrote:
> 
>         Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
>         Author: Sebastian Graf, David Knothe
>         Rendered proposal:
>         https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst <https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst>
>         Discussion:
>         https://github.com/ghc-proposals/ghc-proposals/pull/609
>         <https://github.com/ghc-proposals/ghc-proposals/pull/609>
>         Recommendation: Acceptance
> 
>         ## Summary
> 
>         This proposal refines the syntax of an already accpted proposal
>         (#522) for writing or patterns.
> 
>         The syntax of the old proposal,
> 
>         ```haskell
>         stringOfT :: T -> Maybe String
>         stringOfT (T1 s) = Just s
>         stringOfT (one of T2{}, T3{}) = Nothing
>         ```
> 
>         is replaced with
> 
>         ```haskell
>         stringOfT :: T -> Maybe String
>         stringOfT (T1 s) = Just s
>         stringOfT (T2{}; T3{}) = Nothing
>         ```
> 
>         or indeed
> 
>         ```haskell
>         stringOfT :: T -> Maybe String
>         stringOfT x = case x of
>         T1 s -> Just s
>         T2{}
>         T3{} -> Nothing
>         ```
> 
>         (Beacuse the '(' ... ')' are optional here, we can remove them
>         and naturally exploit layout.)
> 
>         The authors have conducted polls to see what folks preferred,
>         landing on this proposal. The
>         adjustments to the Haskell grammar are really quite minimal
>         requiring one extra production.
> 
>         ## Recommendation
> 
>         The proposal is nondiruptive and as a whole addresses an
>         important practical topic. I recommend
>         that we accept it
> 


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Fri Sep  8 21:42:44 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 8 Sep 2023 14:42:44 -0700
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
References: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
Message-ID: <CAJKmMz8=JaP8x24FVrSeZ_psD_1rn9vZLSLP0cEhOL04NpNNug@mail.gmail.com>

I'm supportive of this proposal in general -- that is, make it easy to find
what the "root" unused bindings are, without cluttering up the warnings
with all the transitively unused ones.

But I have a question (added on the discussion thread) about the ergonomics.

On Fri, 8 Sept 2023 at 03:16, Chris Dornan <chris at chrisdornan.com> wrote:

> Proposal: Fine-Grained Unused Warnings (#42)
> Author: Jakob Brünker
> Rendered proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
> Recommendation: Acceptance
>
> ## Summary
>
> GHC currently warns equally about any superfluous binding that it
> discovers, regardless of whether
> the definition is unreferenced anywhere itself, or is merely mentioned by
> other definitions that are
> similarly superfluous. The proposal proposes to replace these warnings
> with just the warnings about
> definitions that are not referenced anywhere, but list within those
> warnings the entities it
> references that would otherwise not be required. The same information is
> being conveyed under this
> proposal as previously, but in a more structured manner.
>
> The proposal is careful to ensure the -Wunused-* controls
> (-Wunused-top-binds, etc.) are respected,
> so the subwarnings of transitively unused entities are only listed if
> their corresponding -Wunused-*
> control is active.
>
> As Jakob points out in the proposal, getting these warnings into some
> structure is partly motivated
> by IDE usage where the 'additional [transitive] warnings take up a lot of
> valuable screen real
> estate'.
>
> ## Example [From the proposal]
>
> In the following code,
>
> module Foo ()
>
> import Data.List as L
>
> foo = L.intercalate
>
> `intercalate` is transitively unused, since it is only used by `foo`,
> which is unused. The warning
> that's produced will be
>
> Foo.hs:5:1: warning: [-Wunused-top-binds]
> Defined but not used: ‘foo’
> as a consequence the following imports are transitively unused
> [-Wunused-imports]:
> Data.List imported at foo.hs:3:1:
>
> The warning about transitively unused bindings only appears if both the
> warning flag for the unused binding (in this case -Wunused-top-binds) and
> the the one for the transitively unused binding itself (in this case
> -Wunused-imports) are enabled.
>
>
> ## Recommendation
>
> This proposal is not at all disruptive (arguably to the extent of not
> requiring a GHC proposal
> review), is well thought out, and can improve the GHC/IDE UI so I
> recommend that we accept it.
>
> _______________________________________________
> 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/20230908/6a31deb7/attachment.html>

From moritz.angermann at gmail.com  Fri Sep  8 23:26:32 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 9 Sep 2023 07:26:32 +0800
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
Message-ID: <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>

As this breaks accepted code, I’d really like to see this on two steps. At
least one GHC release that warns about

pattern X <- 42 :: Int


Being rejected by GHC going forward. Thus if we get a deprecation warning
for that syntax with the guidance to put the rhs into parentheses, for at
least one release prior to the breaking change, I have no objections.

Moritz

On Sat, 9 Sep 2023 at 3:58 AM, Adam Gundry <adam at well-typed.com> wrote:

> No objections from me. I tend not to pay too much attention to such
> syntactic niceties, but as the authors have gone to the trouble of
> surveying the community and implementing the proposal I see no reason
> not to accept their suggested syntax.
>
> I did notice that the PR drops Ömer's name from the authors list for
> #522, I'm not sure if that was intentional?
>
> Adam
>
>
> On 08/09/2023 18:47, Vladislav Zavialov wrote:
> > In favor
> >
> > On Fri, Sep 8, 2023 at 6:36 PM Simon Peyton Jones
> > <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >
> >     I don't have a strong opinion here.   The authors have done a pretty
> >     diligent job of exploring syntactic alternatives, and seeking
> >     feedback from the community.  I'm quite content to accept this
> >     proposal.  (We have already accepted the base or-pattern proposal,
> >     so that's not our subject for debate.)
> >
> >     Simon
> >
> >     On Fri, 8 Sept 2023 at 03:57, Chris Dornan <chris at chrisdornan.com
> >     <mailto:chris at chrisdornan.com>> wrote:
> >
> >         Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> >         Author: Sebastian Graf, David Knothe
> >         Rendered proposal:
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> >
> >         Discussion:
> >         https://github.com/ghc-proposals/ghc-proposals/pull/609
> >         <https://github.com/ghc-proposals/ghc-proposals/pull/609>
> >         Recommendation: Acceptance
> >
> >         ## Summary
> >
> >         This proposal refines the syntax of an already accpted proposal
> >         (#522) for writing or patterns.
> >
> >         The syntax of the old proposal,
> >
> >         ```haskell
> >         stringOfT :: T -> Maybe String
> >         stringOfT (T1 s) = Just s
> >         stringOfT (one of T2{}, T3{}) = Nothing
> >         ```
> >
> >         is replaced with
> >
> >         ```haskell
> >         stringOfT :: T -> Maybe String
> >         stringOfT (T1 s) = Just s
> >         stringOfT (T2{}; T3{}) = Nothing
> >         ```
> >
> >         or indeed
> >
> >         ```haskell
> >         stringOfT :: T -> Maybe String
> >         stringOfT x = case x of
> >         T1 s -> Just s
> >         T2{}
> >         T3{} -> Nothing
> >         ```
> >
> >         (Beacuse the '(' ... ')' are optional here, we can remove them
> >         and naturally exploit layout.)
> >
> >         The authors have conducted polls to see what folks preferred,
> >         landing on this proposal. The
> >         adjustments to the Haskell grammar are really quite minimal
> >         requiring one extra production.
> >
> >         ## Recommendation
> >
> >         The proposal is nondiruptive and as a whole addresses an
> >         important practical topic. I recommend
> >         that we accept it
> >
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230909/19af9749/attachment.html>

From moritz.angermann at gmail.com  Sat Sep  9 02:12:59 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 9 Sep 2023 10:12:59 +0800
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAJKmMz8=JaP8x24FVrSeZ_psD_1rn9vZLSLP0cEhOL04NpNNug@mail.gmail.com>
References: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
 <CAJKmMz8=JaP8x24FVrSeZ_psD_1rn9vZLSLP0cEhOL04NpNNug@mail.gmail.com>
Message-ID: <CAKfdd-ztAPz9qs1DG3=g1opfqJL_WpfKOe9uwX_86rz1_OySyA@mail.gmail.com>

I’m supportive of this proposal. I think Adam raised a good concern on the
discussion with respect to tooling. As this does not impact GHCs acceptance
of existing code, I’m more lenient towards these changes.

Moritz

On Sat, 9 Sep 2023 at 5:43 AM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I'm supportive of this proposal in general -- that is, make it easy to
> find what the "root" unused bindings are, without cluttering up the
> warnings with all the transitively unused ones.
>
> But I have a question (added on the discussion thread) about the
> ergonomics.
>
> On Fri, 8 Sept 2023 at 03:16, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Proposal: Fine-Grained Unused Warnings (#42)
>> Author: Jakob Brünker
>> Rendered proposal:
>> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>> Recommendation: Acceptance
>>
>> ## Summary
>>
>> GHC currently warns equally about any superfluous binding that it
>> discovers, regardless of whether
>> the definition is unreferenced anywhere itself, or is merely mentioned by
>> other definitions that are
>> similarly superfluous. The proposal proposes to replace these warnings
>> with just the warnings about
>> definitions that are not referenced anywhere, but list within those
>> warnings the entities it
>> references that would otherwise not be required. The same information is
>> being conveyed under this
>> proposal as previously, but in a more structured manner.
>>
>> The proposal is careful to ensure the -Wunused-* controls
>> (-Wunused-top-binds, etc.) are respected,
>> so the subwarnings of transitively unused entities are only listed if
>> their corresponding -Wunused-*
>> control is active.
>>
>> As Jakob points out in the proposal, getting these warnings into some
>> structure is partly motivated
>> by IDE usage where the 'additional [transitive] warnings take up a lot of
>> valuable screen real
>> estate'.
>>
>> ## Example [From the proposal]
>>
>> In the following code,
>>
>> module Foo ()
>>
>> import Data.List as L
>>
>> foo = L.intercalate
>>
>> `intercalate` is transitively unused, since it is only used by `foo`,
>> which is unused. The warning
>> that's produced will be
>>
>> Foo.hs:5:1: warning: [-Wunused-top-binds]
>> Defined but not used: ‘foo’
>> as a consequence the following imports are transitively unused
>> [-Wunused-imports]:
>> Data.List imported at foo.hs:3:1:
>>
>> The warning about transitively unused bindings only appears if both the
>> warning flag for the unused binding (in this case -Wunused-top-binds) and
>> the the one for the transitively unused binding itself (in this case
>> -Wunused-imports) are enabled.
>>
>>
>> ## Recommendation
>>
>> This proposal is not at all disruptive (arguably to the extent of not
>> requiring a GHC proposal
>> review), is well thought out, and can improve the GHC/IDE UI so I
>> recommend that we accept it.
>>
>> _______________________________________________
>> 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/20230909/00ddac4a/attachment-0001.html>

From chris at chrisdornan.com  Sat Sep  9 08:27:10 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sat, 9 Sep 2023 09:27:10 +0100
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CAKfdd-ztAPz9qs1DG3=g1opfqJL_WpfKOe9uwX_86rz1_OySyA@mail.gmail.com>
References: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
 <CAJKmMz8=JaP8x24FVrSeZ_psD_1rn9vZLSLP0cEhOL04NpNNug@mail.gmail.com>
 <CAKfdd-ztAPz9qs1DG3=g1opfqJL_WpfKOe9uwX_86rz1_OySyA@mail.gmail.com>
Message-ID: <2971F4E3-02B5-4DDE-9805-40A888BC8CF9@chrisdornan.com>

Thanks Simon, Moritz and Adam,

I asked Jakob to address Simon's and Tom's suggestions, at least to explain why they don't feature in the current draft.

I have also made it clear we need some downstream tooling input.

Personally, I still like the proposal in the current draft and am hoping Jakob will see a way to resolve the points raised by Tom and Simon without too much disruption.

Chris

> On 9 Sep 2023, at 03:12, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> I’m supportive of this proposal. I think Adam raised a good concern on the discussion with respect to tooling. As this does not impact GHCs acceptance of existing code, I’m more lenient towards these changes.
> 
> Moritz
> 
> On Sat, 9 Sep 2023 at 5:43 AM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>> I'm supportive of this proposal in general -- that is, make it easy to find what the "root" unused bindings are, without cluttering up the warnings with all the transitively unused ones.
>> 
>> But I have a question (added on the discussion thread) about the ergonomics.
>> 
>> On Fri, 8 Sept 2023 at 03:16, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>> Proposal: Fine-Grained Unused Warnings (#42)
>>> Author: Jakob Brünker
>>> Rendered proposal: https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
>>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
>>> Recommendation: Acceptance
>>> 
>>> ## Summary
>>> 
>>> GHC currently warns equally about any superfluous binding that it discovers, regardless of whether
>>> the definition is unreferenced anywhere itself, or is merely mentioned by other definitions that are
>>> similarly superfluous. The proposal proposes to replace these warnings with just the warnings about
>>> definitions that are not referenced anywhere, but list within those warnings the entities it
>>> references that would otherwise not be required. The same information is being conveyed under this
>>> proposal as previously, but in a more structured manner.
>>> 
>>> The proposal is careful to ensure the -Wunused-* controls (-Wunused-top-binds, etc.) are respected,
>>> so the subwarnings of transitively unused entities are only listed if their corresponding -Wunused-*
>>> control is active.
>>> 
>>> As Jakob points out in the proposal, getting these warnings into some structure is partly motivated
>>> by IDE usage where the 'additional [transitive] warnings take up a lot of valuable screen real
>>> estate'.
>>> 
>>> ## Example [From the proposal]
>>> 
>>>     In the following code,
>>> 
>>>         module Foo ()
>>> 
>>>         import Data.List as L
>>> 
>>>         foo = L.intercalate
>>> 
>>>     `intercalate` is transitively unused, since it is only used by `foo`, which is unused. The warning
>>>     that's produced will be
>>> 
>>>         Foo.hs:5:1: warning: [-Wunused-top-binds]
>>>             Defined but not used: ‘foo’
>>>             as a consequence the following imports are transitively unused [-Wunused-imports]:
>>>               Data.List imported at foo.hs:3:1:
>>> 
>>>     The warning about transitively unused bindings only appears if both the warning flag for the unused binding (in this case -Wunused-top-binds) and the the one for the transitively unused binding itself (in this case -Wunused-imports) are enabled.
>>> 
>>> 
>>> ## Recommendation
>>> 
>>> This proposal is not at all disruptive (arguably to the extent of not requiring a GHC proposal
>>> review), is well thought out, and can improve the GHC/IDE UI so I recommend that we accept it.
>>> 
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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/20230909/f37a074d/attachment.html>

From marlowsd at gmail.com  Sat Sep  9 15:43:31 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 9 Sep 2023 08:43:31 -0700
Subject: [ghc-steering-committee] Fine-Grained Unused Warnings (#42)
In-Reply-To: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
References: <CABSB5jXgECoW+mG0NDDhYV2T2dJUnAzgenrbm0qevvZ-NJaR_Q@mail.gmail.com>
Message-ID: <CANsrgPJtBgftfBsY0gRvy0xLnp1VNKGwUaU1ZM6unSEBPLcZRA@mail.gmail.com>

I mentioned on the github thread that I think this will impact some tooling
(the emacs mode in particular). I do think that moving away from the simple
format of each error/warning having a separate source range in an
easy-to-parse format is not something we should do lightly. That's useful
both for humans and computers, I would argue.

On Fri, 8 Sept 2023 at 03:16, Chris Dornan <chris at chrisdornan.com> wrote:

> Proposal: Fine-Grained Unused Warnings (#42)
> Author: Jakob Brünker
> Rendered proposal:
> https://github.com/JakobBruenker/ghc-proposals/blob/fine-grained-unused/proposals/0000-fine-grained-unused-warnings.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/434
> Recommendation: Acceptance
>
> ## Summary
>
> GHC currently warns equally about any superfluous binding that it
> discovers, regardless of whether
> the definition is unreferenced anywhere itself, or is merely mentioned by
> other definitions that are
> similarly superfluous. The proposal proposes to replace these warnings
> with just the warnings about
> definitions that are not referenced anywhere, but list within those
> warnings the entities it
> references that would otherwise not be required. The same information is
> being conveyed under this
> proposal as previously, but in a more structured manner.
>
> The proposal is careful to ensure the -Wunused-* controls
> (-Wunused-top-binds, etc.) are respected,
> so the subwarnings of transitively unused entities are only listed if
> their corresponding -Wunused-*
> control is active.
>
> As Jakob points out in the proposal, getting these warnings into some
> structure is partly motivated
> by IDE usage where the 'additional [transitive] warnings take up a lot of
> valuable screen real
> estate'.
>
> ## Example [From the proposal]
>
> In the following code,
>
> module Foo ()
>
> import Data.List as L
>
> foo = L.intercalate
>
> `intercalate` is transitively unused, since it is only used by `foo`,
> which is unused. The warning
> that's produced will be
>
> Foo.hs:5:1: warning: [-Wunused-top-binds]
> Defined but not used: ‘foo’
> as a consequence the following imports are transitively unused
> [-Wunused-imports]:
> Data.List imported at foo.hs:3:1:
>
> The warning about transitively unused bindings only appears if both the
> warning flag for the unused binding (in this case -Wunused-top-binds) and
> the the one for the transitively unused binding itself (in this case
> -Wunused-imports) are enabled.
>
>
> ## Recommendation
>
> This proposal is not at all disruptive (arguably to the extent of not
> requiring a GHC proposal
> review), is well thought out, and can improve the GHC/IDE UI so I
> recommend that we accept it.
>
> _______________________________________________
> 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/20230909/3d95fc9b/attachment.html>

From simon.peytonjones at gmail.com  Sun Sep 10 02:06:55 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sat, 9 Sep 2023 19:06:55 -0700
Subject: [ghc-steering-committee] GHC steering committee status
Message-ID: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>

Dear GHC steering committee

Re GHC proposals I was talking to Simon M about

   - Making the shepherd's job easier and quicker
   - Providing a way for members of the committee to say (explicitly) "I
   don't have an opinion about this proposal" and thus recuse themselves.
   Explicit recusal is better than "silence means assent" because silence can,
   and often does, mean "I'm under water and not listening".

With that in mind, I want to revive my suggestion of running an online
spreadsheet
<https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
describe the state of proposals that are in our active purview.  That is,
I'm not proposing to show proposals that are under discussion by the
community, or accepted etc -- just the ones that are in our inbox, *where
the next action is ours.*

That makes it much easier to see our current inbox, without looking back
for Jocahim's last email and then adding deltas for all the emails since --
which I cannot do in my head.

Specifically, I have *a column for each committee member's vote. * That
should make it easy for the shepherd to see who is yet to express an
opinion, which I always find difficult.

As I say above, I am very uncomfortable with "silence means assent" for any
but the smallest proposals.  *I suggest instead that if there is a proposal
where you feel unable to offer an opinion, due to lack of expertise, or
lack of time, you can say "recuse" meaning that you explicitly want to
stand down from this particular proposal.*   (Somehow "abstain" carries a
connotation of conflict of interest or something, but it amounts to the
same thing.)  If you are too  under water to even recuse yourself, maybe
it's time to step down.

So in columns F to O we should see explicit responses from every committee
member, in a timely way.

Joachim doesn't like spreadsheets like this because they can easily get out
of date.  But it must be better than manually trawling email. *And it is up
to each of us (not Joachim) to fill in our own column for proposals in our
inbox.*

If we don't like it, we can change it.  You all have edit rights.

I have populated it with data from Joachim's message of 2 Sept, but there
has been some action since then, so shepherds please update it.  This is
not Joachim's task!

Thanks

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

From moritz.angermann at gmail.com  Sun Sep 10 02:36:13 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 10 Sep 2023 10:36:13 +0800
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
Message-ID: <CAKfdd-yFJo=5XPqnZuZWAhaekQEPVXnGS5y0KUM0HWtRp6LRxQ@mail.gmail.com>

Simon,

I think this is a good idea!  Is my understanding correct that this is for
record keeping by the shepherd only? It is not sufficient for steering
committee members to go over the proposal and just fill out
accept/reject/recuse in their respective column? Emails are still the
authorative events?

Cheers,
  Moritz

On Sun, 10 Sep 2023 at 10:07 AM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC steering committee
>
> Re GHC proposals I was talking to Simon M about
>
>    - Making the shepherd's job easier and quicker
>    - Providing a way for members of the committee to say (explicitly) "I
>    don't have an opinion about this proposal" and thus recuse themselves.
>    Explicit recusal is better than "silence means assent" because silence can,
>    and often does, mean "I'm under water and not listening".
>
> With that in mind, I want to revive my suggestion of running an online
> spreadsheet
> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
> describe the state of proposals that are in our active purview.  That is,
> I'm not proposing to show proposals that are under discussion by the
> community, or accepted etc -- just the ones that are in our inbox, *where
> the next action is ours.*
>
> That makes it much easier to see our current inbox, without looking back
> for Jocahim's last email and then adding deltas for all the emails since --
> which I cannot do in my head.
>
> Specifically, I have *a column for each committee member's vote. * That
> should make it easy for the shepherd to see who is yet to express an
> opinion, which I always find difficult.
>
> As I say above, I am very uncomfortable with "silence means assent" for
> any but the smallest proposals.  *I suggest instead that if there is a
> proposal where you feel unable to offer an opinion, due to lack of
> expertise, or lack of time, you can say "recuse" meaning that you
> explicitly want to stand down from this particular proposal.*   (Somehow
> "abstain" carries a connotation of conflict of interest or something, but
> it amounts to the same thing.)  If you are too  under water to even recuse
> yourself, maybe it's time to step down.
>
> So in columns F to O we should see explicit responses from every committee
> member, in a timely way.
>
> Joachim doesn't like spreadsheets like this because they can easily get
> out of date.  But it must be better than manually trawling email. *And it
> is up to each of us (not Joachim) to fill in our own column for proposals
> in our inbox.*
>
> If we don't like it, we can change it.  You all have edit rights.
>
> I have populated it with data from Joachim's message of 2 Sept, but there
> has been some action since then, so shepherds please update it.  This is
> not Joachim's task!
>
> Thanks
>
> Simon
>
>
>
>
>
>
> _______________________________________________
> 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/20230910/c5050426/attachment-0001.html>

From mail at joachim-breitner.de  Sun Sep 10 04:04:31 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 9 Sep 2023 21:04:31 -0700 (PDT)
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
Message-ID: <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>

Hi,

since this is guarded by an extension that doesn't even exist yet, no code is broken, is there?

I also don't expect this to be enabled in the future without coinciding with an intentional action by the developers - enabling this extension or switching to a future language edition that has this enabled by default (should that ever exist). Is it not sufficient if they are _then_ bothered with this change?

(That said, we could say that a unparenthized type annotation on a pattern synonym is simply confusing, and thus use a warning to nudge the developers to add the parentheses now.)

So not opposed to an early warning, I just don't think it's strictly necessary for this change.

Cheers,
Joachim

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

From moritz.angermann at gmail.com  Sun Sep 10 04:16:26 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 10 Sep 2023 12:16:26 +0800
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
Message-ID: <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>

Joachim,

My understand if the cost and drawbacks section[1], is that existing code
breaks even without explicitly enabling the extension. If this is indeed
not the case it should be called our explicitly in the section that
breakage requires the extension to be enabled. Also an explanation why the
patsyn test cases fail. Do we automatically enable that extension in the
testsuite? Where does the regression come from?

Maybe I’m misreading that section and it just needs to be clarified that
there is _no breakage without **explixitly** enabling the extension_ to
existing code.

Cheers,
 Moritz

[1]:
https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks

On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> since this is guarded by an extension that doesn't even exist yet, no code
> is broken, is there?
>
> I also don't expect this to be enabled in the future without coinciding
> with an intentional action by the developers - enabling this extension or
> switching to a future language edition that has this enabled by default
> (should that ever exist). Is it not sufficient if they are _then_ bothered
> with this change?
>
> (That said, we could say that a unparenthized type annotation on a pattern
> synonym is simply confusing, and thus use a warning to nudge the developers
> to add the parentheses now.)
>
> So not opposed to an early warning, I just don't think it's strictly
> necessary for this change.
>
> Cheers,
> Joachim
>
> _______________________________________________
> 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/20230910/dd110fcc/attachment.html>

From mail at joachim-breitner.de  Sun Sep 10 04:47:19 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 9 Sep 2023 21:47:19 -0700 (PDT)
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
Message-ID: <a0738583-b386-4b2e-abb7-45309e9c5a6b@joachim-breitner.de>

09.09.2023 21:17:01 Moritz Angermann <moritz.angermann at gmail.com>:

> Joachim,
> 
> My understand if the cost and drawbacks section[1], is that existing code breaks even without explicitly enabling the extension. If this is indeed not the case it should be called our explicitly in the section that breakage requires the extension to be enabled. Also an explanation why the patsyn test cases fail. Do we automatically enable that extension in the testsuite? Where does the regression come from?
> 
> Maybe I’m misreading that section and it just needs to be clarified that there is _no breakage without **explixitly** enabling the extension_ to existing code. 
> 
> Cheers,
>  Moritz
> 
> [1]: 
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
> 
> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Hi,
> 
> since this is guarded by an extension that doesn't even exist yet, no code is broken, is there?
> 
> I also don't expect this to be enabled in the future without coinciding with an intentional action by the developers - enabling this extension or switching to a future language edition that has this enabled by default (should that ever exist). Is it not sufficient if they are _then_ bothered with this change?
> 
> (That said, we could say that a unparenthized type annotation on a pattern synonym is simply confusing, and thus use a warning to nudge the developers to add the parentheses now.)
> 
> So not opposed to an early warning, I just don't think it's strictly necessary for this change.
> 
> Cheers,
> Joachim
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi,

I would assume that all this only applies under {- LANGUAGE Or Patterns -}, but it seems it's not actually explicitly stated as such.

I understand the breakage section as “what code needs to be changed when you enable the extension”. But maybe that's too optimistic?

Chris, can you get clarification on this?

Mortiz, assuming all changes are guarded by an extension, do you agree that no early warning would be necessary?

Cheers,
Joachim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230909/987cc85a/attachment.html>

From moritz.angermann at gmail.com  Sun Sep 10 05:26:06 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sun, 10 Sep 2023 13:26:06 +0800
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <a0738583-b386-4b2e-abb7-45309e9c5a6b@joachim-breitner.de>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <a0738583-b386-4b2e-abb7-45309e9c5a6b@joachim-breitner.de>
Message-ID: <CAKfdd-wDj5mFBy6J==QuhrLYzCtOnosC60o9C87KJpDKVd19eg@mail.gmail.com>

Joachim,

I have absolutely no issue with new extensions rejecting code that compiles
fine without them. My only objections is to GHC not accepting code it
accepted before without a deprecation period in between.

The only thing I object is GHC X compiling code just fine and GHC X+1
rejecting the exact same code.

Imo I think only X+3 should be permitted to reject code that X compiled.
And X+1 and X+2 should warn about the upcoming change to syntax.

But I can compromise on X+2, with X+1 having deprecation warnings.

What I am unwilling to permit is X+1 rejecting code that X accepted without
warning. That is sudden breakage of code.

This form of basic absolutely minimal backwards compatibility is absolutely
essential for proper regression testing of the compiler. If I can not
trivially swap out the compiler in a working codebase, we have no hope for
proper regression testing or quality control.

Best,
 Moritz

On Sun, 10 Sep 2023 at 12:47 PM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> 09.09.2023 21:17:01 Moritz Angermann <moritz.angermann at gmail.com>:
>
> Joachim,
>
> My understand if the cost and drawbacks section[1], is that existing code
> breaks even without explicitly enabling the extension. If this is indeed
> not the case it should be called our explicitly in the section that
> breakage requires the extension to be enabled. Also an explanation why the
> patsyn test cases fail. Do we automatically enable that extension in the
> testsuite? Where does the regression come from?
>
> Maybe I’m misreading that section and it just needs to be clarified that
> there is _no breakage without **explixitly** enabling the extension_ to
> existing code.
>
> Cheers,
>  Moritz
>
> [1]:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>
> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Hi,
>>
>> since this is guarded by an extension that doesn't even exist yet, no
>> code is broken, is there?
>>
>> I also don't expect this to be enabled in the future without coinciding
>> with an intentional action by the developers - enabling this extension or
>> switching to a future language edition that has this enabled by default
>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>> with this change?
>>
>> (That said, we could say that a unparenthized type annotation on a
>> pattern synonym is simply confusing, and thus use a warning to nudge the
>> developers to add the parentheses now.)
>>
>> So not opposed to an early warning, I just don't think it's strictly
>> necessary for this change.
>>
>> Cheers,
>> Joachim
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> Hi,
>
> I would assume that all this only applies under {- LANGUAGE Or Patterns
> -}, but it seems it's not actually explicitly stated as such.
>
> I understand the breakage section as “what code needs to be changed when
> you enable the extension”. But maybe that's too optimistic?
>
> Chris, can you get clarification on this?
>
> Mortiz, assuming all changes are guarded by an extension, do you agree
> that no early warning would be necessary?
>
> Cheers,
> Joachim
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230910/535732ca/attachment-0001.html>

From arnaud.spiwack at tweag.io  Sun Sep 10 17:11:20 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Sun, 10 Sep 2023 19:11:20 +0200
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAKfdd-wDj5mFBy6J==QuhrLYzCtOnosC60o9C87KJpDKVd19eg@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <a0738583-b386-4b2e-abb7-45309e9c5a6b@joachim-breitner.de>
 <CAKfdd-wDj5mFBy6J==QuhrLYzCtOnosC60o9C87KJpDKVd19eg@mail.gmail.com>
Message-ID: <CAGwnsnnXmgUUdn_wE0UHuCk9GXreSp71VrivF9P2JFhq9Mo3MQ@mail.gmail.com>

I'm in favour of acceptance. The possibility to use layout, like in Chris's
example in his recommendation email, is especially convincing to me: in
Ocaml, many or patterns are layed out that way (despite the fact that
Ocaml's grammar is insensitive to layout). Something like

foo = function
  | A -> a
  | B
  | C -> b
  | D -> d

It feels very natural there, it'll feel natural in Haskell too.

---

Regarding backward compatibility, my understanding is the same as Moritz:
in its current text, pattern synonyms are parsed differently regardless of
whether -XOrPattern is turned on. This looks like a rather minor breakage,
so I'm happy to follow the rest of the committee on the stance to take
regarding this breakage. However, I would point out that this change to the
pattern synonym syntax doesn't appear to be motivated in the text, at least
it's not immediately apparent to me why it was deemed necessary. Maybe I
missed something?

On Sun, 10 Sept 2023 at 07:26, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Joachim,
>
> I have absolutely no issue with new extensions rejecting code that
> compiles fine without them. My only objections is to GHC not accepting code
> it accepted before without a deprecation period in between.
>
> The only thing I object is GHC X compiling code just fine and GHC X+1
> rejecting the exact same code.
>
> Imo I think only X+3 should be permitted to reject code that X compiled.
> And X+1 and X+2 should warn about the upcoming change to syntax.
>
> But I can compromise on X+2, with X+1 having deprecation warnings.
>
> What I am unwilling to permit is X+1 rejecting code that X accepted
> without warning. That is sudden breakage of code.
>
> This form of basic absolutely minimal backwards compatibility is
> absolutely essential for proper regression testing of the compiler. If I
> can not trivially swap out the compiler in a working codebase, we have no
> hope for proper regression testing or quality control.
>
> Best,
>  Moritz
>
> On Sun, 10 Sep 2023 at 12:47 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> 09.09.2023 21:17:01 Moritz Angermann <moritz.angermann at gmail.com>:
>>
>> Joachim,
>>
>> My understand if the cost and drawbacks section[1], is that existing code
>> breaks even without explicitly enabling the extension. If this is indeed
>> not the case it should be called our explicitly in the section that
>> breakage requires the extension to be enabled. Also an explanation why the
>> patsyn test cases fail. Do we automatically enable that extension in the
>> testsuite? Where does the regression come from?
>>
>> Maybe I’m misreading that section and it just needs to be clarified that
>> there is _no breakage without **explixitly** enabling the extension_ to
>> existing code.
>>
>> Cheers,
>>  Moritz
>>
>> [1]:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>>
>> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> since this is guarded by an extension that doesn't even exist yet, no
>>> code is broken, is there?
>>>
>>> I also don't expect this to be enabled in the future without coinciding
>>> with an intentional action by the developers - enabling this extension or
>>> switching to a future language edition that has this enabled by default
>>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>>> with this change?
>>>
>>> (That said, we could say that a unparenthized type annotation on a
>>> pattern synonym is simply confusing, and thus use a warning to nudge the
>>> developers to add the parentheses now.)
>>>
>>> So not opposed to an early warning, I just don't think it's strictly
>>> necessary for this change.
>>>
>>> Cheers,
>>> Joachim
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> Hi,
>>
>> I would assume that all this only applies under {- LANGUAGE Or Patterns
>> -}, but it seems it's not actually explicitly stated as such.
>>
>> I understand the breakage section as “what code needs to be changed when
>> you enable the extension”. But maybe that's too optimistic?
>>
>> Chris, can you get clarification on this?
>>
>> Mortiz, assuming all changes are guarded by an extension, do you agree
>> that no early warning would be necessary?
>>
>> Cheers,
>> Joachim
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230910/380b39e1/attachment.html>

From chris at chrisdornan.com  Mon Sep 11 03:48:11 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 11 Sep 2023 04:48:11 +0100
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
Message-ID: <8CF1A245-BA13-4799-B12E-149BF96C677B@chrisdornan.com>

While I think the spreadsheet is really nice, I have to say I am personally comfortable with Joachim's periodic summaries and his ability to read the room as to whether a proposal has the support of the committee.

If folks don't have time to respond for feedback then that is just the way it is and enough of the remainder of the committee have weighed in then I think we just move on. If Joachim is aware of missing coverage in any response then he waits until we have satisfactory coverage.

I am not saying we could not do better, but, for my needs, Joachim is managing everything pretty optimally.

Of course we all have way of working so it would be really good if folks could indicate whether they want (1) the old way (2) the way of the spreadsheet or (3) some hybrid.

I suspect we might want to consider a hybrid -- if so, do we need to find an assistant to Joachim to maintain the spreadsheet? (Let's not add to Joachim's workload but share it.)

Chris


> On 10 Sep 2023, at 03:06, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Dear GHC steering committee
> 
> Re GHC proposals I was talking to Simon M about
> Making the shepherd's job easier and quicker
> Providing a way for members of the committee to say (explicitly) "I don't have an opinion about this proposal" and thus recuse themselves.   Explicit recusal is better than "silence means assent" because silence can, and often does, mean "I'm under water and not listening".
> With that in mind, I want to revive my suggestion of running an online spreadsheet  <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to describe the state of proposals that are in our active purview.  That is, I'm not proposing to show proposals that are under discussion by the community, or accepted etc -- just the ones that are in our inbox, where the next action is ours.
> 
> That makes it much easier to see our current inbox, without looking back for Jocahim's last email and then adding deltas for all the emails since -- which I cannot do in my head.
> 
> Specifically, I have a column for each committee member's vote.  That should make it easy for the shepherd to see who is yet to express an opinion, which I always find difficult.
> 
> As I say above, I am very uncomfortable with "silence means assent" for any but the smallest proposals.  I suggest instead that if there is a proposal where you feel unable to offer an opinion, due to lack of expertise, or lack of time, you can say "recuse" meaning that you explicitly want to stand down from this particular proposal.   (Somehow "abstain" carries a connotation of conflict of interest or something, but it amounts to the same thing.)  If you are too  under water to even recuse yourself, maybe it's time to step down.
> 
> So in columns F to O we should see explicit responses from every committee member, in a timely way.
> 
> Joachim doesn't like spreadsheets like this because they can easily get out of date.  But it must be better than manually trawling email. And it is up to each of us (not Joachim) to fill in our own column for proposals in our inbox.
> 
> If we don't like it, we can change it.  You all have edit rights.
> 
> I have populated it with data from Joachim's message of 2 Sept, but there has been some action since then, so shepherds please update it.  This is not Joachim's task!
> 
> Thanks
> 
> Simon
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/20230911/76230b02/attachment-0001.html>

From chris at chrisdornan.com  Mon Sep 11 03:57:09 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 11 Sep 2023 04:57:09 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
 p2 (#609)
In-Reply-To: <CAGwnsnnXmgUUdn_wE0UHuCk9GXreSp71VrivF9P2JFhq9Mo3MQ@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <a0738583-b386-4b2e-abb7-45309e9c5a6b@joachim-breitner.de>
 <CAKfdd-wDj5mFBy6J==QuhrLYzCtOnosC60o9C87KJpDKVd19eg@mail.gmail.com>
 <CAGwnsnnXmgUUdn_wE0UHuCk9GXreSp71VrivF9P2JFhq9Mo3MQ@mail.gmail.com>
Message-ID: <0ABF1BCD-2EF7-4E03-89C8-23E340CFA816@chrisdornan.com>

With regards backwards compatibility I have asked the authors to clarify whether implementing the proposal is expected to break anything when the extension is not enabled.

Chris

> On 10 Sep 2023, at 18:11, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I'm in favour of acceptance. The possibility to use layout, like in Chris's example in his recommendation email, is especially convincing to me: in Ocaml, many or patterns are layed out that way (despite the fact that Ocaml's grammar is insensitive to layout). Something like
> 
> foo = function
>   | A -> a
>   | B
>   | C -> b
>   | D -> d
> 
> It feels very natural there, it'll feel natural in Haskell too.
> 
> ---
> 
> Regarding backward compatibility, my understanding is the same as Moritz: in its current text, pattern synonyms are parsed differently regardless of whether -XOrPattern is turned on. This looks like a rather minor breakage, so I'm happy to follow the rest of the committee on the stance to take regarding this breakage. However, I would point out that this change to the pattern synonym syntax doesn't appear to be motivated in the text, at least it's not immediately apparent to me why it was deemed necessary. Maybe I missed something?
> 
> On Sun, 10 Sept 2023 at 07:26, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> Joachim,
>> 
>> I have absolutely no issue with new extensions rejecting code that compiles fine without them. My only objections is to GHC not accepting code it accepted before without a deprecation period in between.
>> 
>> The only thing I object is GHC X compiling code just fine and GHC X+1 rejecting the exact same code.
>> 
>> Imo I think only X+3 should be permitted to reject code that X compiled. And X+1 and X+2 should warn about the upcoming change to syntax.
>> 
>> But I can compromise on X+2, with X+1 having deprecation warnings.
>> 
>> What I am unwilling to permit is X+1 rejecting code that X accepted without warning. That is sudden breakage of code.
>> 
>> This form of basic absolutely minimal backwards compatibility is absolutely essential for proper regression testing of the compiler. If I can not trivially swap out the compiler in a working codebase, we have no hope for proper regression testing or quality control.
>> 
>> Best,
>>  Moritz
>> 
>> On Sun, 10 Sep 2023 at 12:47 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>> 09.09.2023 21:17:01 Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>>:
>>> 
>>> Joachim,
>>> 
>>> My understand if the cost and drawbacks section[1], is that existing code breaks even without explicitly enabling the extension. If this is indeed not the case it should be called our explicitly in the section that breakage requires the extension to be enabled. Also an explanation why the patsyn test cases fail. Do we automatically enable that extension in the testsuite? Where does the regression come from?
>>> 
>>> Maybe I’m misreading that section and it just needs to be clarified that there is _no breakage without **explixitly** enabling the extension_ to existing code. 
>>> 
>>> Cheers,
>>>  Moritz
>>> 
>>> [1]: 
>>> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>>> 
>>> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>>> Hi, 
>>>> 
>>>> since this is guarded by an extension that doesn't even exist yet, no code is broken, is there? 
>>>> 
>>>> I also don't expect this to be enabled in the future without coinciding with an intentional action by the developers - enabling this extension or switching to a future language edition that has this enabled by default (should that ever exist). Is it not sufficient if they are _then_ bothered with this change? 
>>>> 
>>>> (That said, we could say that a unparenthized type annotation on a pattern synonym is simply confusing, and thus use a warning to nudge the developers to add the parentheses now.) 
>>>> 
>>>> So not opposed to an early warning, I just don't think it's strictly necessary for this change. 
>>>> 
>>>> Cheers, 
>>>> Joachim 
>>>> 
>>>> _______________________________________________
>>>> 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
>>> 
>>> Hi, 
>>> 
>>> I would assume that all this only applies under {- LANGUAGE Or Patterns -}, but it seems it's not actually explicitly stated as such. 
>>> 
>>> I understand the breakage section as “what code needs to be changed when you enable the extension”. But maybe that's too optimistic? 
>>> 
>>> Chris, can you get clarification on this? 
>>> 
>>> Mortiz, assuming all changes are guarded by an extension, do you agree that no early warning would be necessary? 
>>> 
>>> Cheers, 
>>> Joachim
>> _______________________________________________
>> 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
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20230911/556879ae/attachment.html>

From simon.peytonjones at gmail.com  Mon Sep 11 08:46:26 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Sep 2023 09:46:26 +0100
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <8CF1A245-BA13-4799-B12E-149BF96C677B@chrisdornan.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
 <8CF1A245-BA13-4799-B12E-149BF96C677B@chrisdornan.com>
Message-ID: <CAJKmMz-4x7vdc4K-vQ1kzxdCNGYx9Ypbbe5uTP15gMDU2zNXqA@mail.gmail.com>

>
> I suspect we might want to consider a hybrid -- if so, do we need to find
> an assistant to Joachim to maintain the spreadsheet? (Let's not add to
> Joachim's workload but share it.)
>

Aha -- I should have been clearer.  I never intended to suggest that
Joachim alone would maintain the spreadsheet.  We all will!  It took me
about 20 mins to put together the entire status quo before sending my
email.  I think it would take an extra thirty seconds or so for us to each
update it with our votes, and view others.

For me it'll reduce my workload, because I won't have to scroll through
dozens of messages to reconstruct the current state of play.

I'm going to give it a try anyway.  Even if no one else joins it, it'll be
helpful to me.  But I hope you will.

Simon

On Mon, 11 Sept 2023 at 04:48, Chris Dornan <chris at chrisdornan.com> wrote:

> While I think the spreadsheet is really nice, I have to say I am
> personally comfortable with Joachim's periodic summaries and his ability to
> read the room as to whether a proposal has the support of the committee.
>
> If folks don't have time to respond for feedback then that is just the way
> it is and enough of the remainder of the committee have weighed in then I
> think we just move on. If Joachim is aware of missing coverage in any
> response then he waits until we have satisfactory coverage.
>
> I am not saying we could not do better, but, for my needs, Joachim is
> managing everything pretty optimally.
>
> Of course we all have way of working so it would be really good if folks
> could indicate whether they want (1) the old way (2) the way of the
> spreadsheet or (3) some hybrid.
>
> I suspect we might want to consider a hybrid -- if so, do we need to find
> an assistant to Joachim to maintain the spreadsheet? (Let's not add to
> Joachim's workload but share it.)
>
> Chris
>
>
> On 10 Sep 2023, at 03:06, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Dear GHC steering committee
>
> Re GHC proposals I was talking to Simon M about
>
>    - Making the shepherd's job easier and quicker
>    - Providing a way for members of the committee to say (explicitly) "I
>    don't have an opinion about this proposal" and thus recuse themselves.
>    Explicit recusal is better than "silence means assent" because silence can,
>    and often does, mean "I'm under water and not listening".
>
> With that in mind, I want to revive my suggestion of running an online
> spreadsheet
> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
> describe the state of proposals that are in our active purview.  That is,
> I'm not proposing to show proposals that are under discussion by the
> community, or accepted etc -- just the ones that are in our inbox, *where
> the next action is ours.*
>
> That makes it much easier to see our current inbox, without looking back
> for Jocahim's last email and then adding deltas for all the emails since --
> which I cannot do in my head.
>
> Specifically, I have *a column for each committee member's vote. * That
> should make it easy for the shepherd to see who is yet to express an
> opinion, which I always find difficult.
>
> As I say above, I am very uncomfortable with "silence means assent" for
> any but the smallest proposals.  *I suggest instead that if there is a
> proposal where you feel unable to offer an opinion, due to lack of
> expertise, or lack of time, you can say "recuse" meaning that you
> explicitly want to stand down from this particular proposal.*   (Somehow
> "abstain" carries a connotation of conflict of interest or something, but
> it amounts to the same thing.)  If you are too  under water to even recuse
> yourself, maybe it's time to step down.
>
> So in columns F to O we should see explicit responses from every committee
> member, in a timely way.
>
> Joachim doesn't like spreadsheets like this because they can easily get
> out of date.  But it must be better than manually trawling email. *And it
> is up to each of us (not Joachim) to fill in our own column for proposals
> in our inbox.*
>
> If we don't like it, we can change it.  You all have edit rights.
>
> I have populated it with data from Joachim's message of 2 Sept, but there
> has been some action since then, so shepherds please update it.  This is
> not Joachim's task!
>
> Thanks
>
> Simon
>
>
>
>
>
>
> _______________________________________________
> 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/20230911/4b3e58ae/attachment-0001.html>

From marlowsd at gmail.com  Mon Sep 11 09:46:31 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 11 Sep 2023 10:46:31 +0100
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CAKfdd-yFJo=5XPqnZuZWAhaekQEPVXnGS5y0KUM0HWtRp6LRxQ@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
 <CAKfdd-yFJo=5XPqnZuZWAhaekQEPVXnGS5y0KUM0HWtRp6LRxQ@mail.gmail.com>
Message-ID: <CANsrgP+NZTacyK-k9K7A4L04b5YuRStRSLLx47ffC8Mv_7rR3w@mail.gmail.com>

I think Simon intends the spreadsheet to be the source of truth for votes
by committee members, because he wanted something more explicit than just
silence to indicate "I have no strong views on this proposal". FWIW I think
it's reasonable to expect *some* action by committee members for each
proposal. I'm not wildly enthusiastic about the spreadsheet because it's
another thing separate from github and email, and it's a bit manual for my
liking, but happy to go with it if that's what people want.

One disadvantage of the spreadsheet is that it's not as transparent as the
other mechanisms we use for this committee (email and It should probably be
visible to all and linked from the docs on github?

Cheers
Simon

On Sun, 10 Sept 2023 at 03:36, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Simon,
>
> I think this is a good idea!  Is my understanding correct that this is for
> record keeping by the shepherd only? It is not sufficient for steering
> committee members to go over the proposal and just fill out
> accept/reject/recuse in their respective column? Emails are still the
> authorative events?
>
> Cheers,
>   Moritz
>
> On Sun, 10 Sep 2023 at 10:07 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Dear GHC steering committee
>>
>> Re GHC proposals I was talking to Simon M about
>>
>>    - Making the shepherd's job easier and quicker
>>    - Providing a way for members of the committee to say (explicitly) "I
>>    don't have an opinion about this proposal" and thus recuse themselves.
>>    Explicit recusal is better than "silence means assent" because silence can,
>>    and often does, mean "I'm under water and not listening".
>>
>> With that in mind, I want to revive my suggestion of running an online
>> spreadsheet
>> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
>> describe the state of proposals that are in our active purview.  That is,
>> I'm not proposing to show proposals that are under discussion by the
>> community, or accepted etc -- just the ones that are in our inbox, *where
>> the next action is ours.*
>>
>> That makes it much easier to see our current inbox, without looking back
>> for Jocahim's last email and then adding deltas for all the emails since --
>> which I cannot do in my head.
>>
>> Specifically, I have *a column for each committee member's vote. * That
>> should make it easy for the shepherd to see who is yet to express an
>> opinion, which I always find difficult.
>>
>> As I say above, I am very uncomfortable with "silence means assent" for
>> any but the smallest proposals.  *I suggest instead that if there is a
>> proposal where you feel unable to offer an opinion, due to lack of
>> expertise, or lack of time, you can say "recuse" meaning that you
>> explicitly want to stand down from this particular proposal.*   (Somehow
>> "abstain" carries a connotation of conflict of interest or something, but
>> it amounts to the same thing.)  If you are too  under water to even recuse
>> yourself, maybe it's time to step down.
>>
>> So in columns F to O we should see explicit responses from every
>> committee member, in a timely way.
>>
>> Joachim doesn't like spreadsheets like this because they can easily get
>> out of date.  But it must be better than manually trawling email. *And
>> it is up to each of us (not Joachim) to fill in our own column for
>> proposals in our inbox.*
>>
>> If we don't like it, we can change it.  You all have edit rights.
>>
>> I have populated it with data from Joachim's message of 2 Sept, but there
>> has been some action since then, so shepherds please update it.  This is
>> not Joachim's task!
>>
>> Thanks
>>
>> Simon
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20230911/19c15617/attachment.html>

From marlowsd at gmail.com  Mon Sep 11 09:48:33 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 11 Sep 2023 10:48:33 +0100
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CANsrgP+NZTacyK-k9K7A4L04b5YuRStRSLLx47ffC8Mv_7rR3w@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
 <CAKfdd-yFJo=5XPqnZuZWAhaekQEPVXnGS5y0KUM0HWtRp6LRxQ@mail.gmail.com>
 <CANsrgP+NZTacyK-k9K7A4L04b5YuRStRSLLx47ffC8Mv_7rR3w@mail.gmail.com>
Message-ID: <CANsrgP+rD4NRwUeaQU6AY6cQWs4G_9d-g5MOiaUosAcb4Ypwfw@mail.gmail.com>

On Mon, 11 Sept 2023 at 10:46, Simon Marlow <marlowsd at gmail.com> wrote:

> I think Simon intends the spreadsheet to be the source of truth for votes
> by committee members, because he wanted something more explicit than just
> silence to indicate "I have no strong views on this proposal". FWIW I think
> it's reasonable to expect *some* action by committee members for each
> proposal. I'm not wildly enthusiastic about the spreadsheet because it's
> another thing separate from github and email, and it's a bit manual for my
> liking, but happy to go with it if that's what people want.
>
> One disadvantage of the spreadsheet is that it's not as transparent as the
> other mechanisms we use for this committee (email and It should probably be
> visible to all and linked from the docs on github?
>

That should have read:

One disadvantage of the spreadsheet is that it's not as transparent as the
other mechanisms we use for this committee (email and github). It should
probably be visible to all and linked from the docs on github?


>
> Cheers
> Simon
>
> On Sun, 10 Sept 2023 at 03:36, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> Simon,
>>
>> I think this is a good idea!  Is my understanding correct that this is
>> for record keeping by the shepherd only? It is not sufficient for steering
>> committee members to go over the proposal and just fill out
>> accept/reject/recuse in their respective column? Emails are still the
>> authorative events?
>>
>> Cheers,
>>   Moritz
>>
>> On Sun, 10 Sep 2023 at 10:07 AM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> Dear GHC steering committee
>>>
>>> Re GHC proposals I was talking to Simon M about
>>>
>>>    - Making the shepherd's job easier and quicker
>>>    - Providing a way for members of the committee to say (explicitly)
>>>    "I don't have an opinion about this proposal" and thus recuse themselves.
>>>    Explicit recusal is better than "silence means assent" because silence can,
>>>    and often does, mean "I'm under water and not listening".
>>>
>>> With that in mind, I want to revive my suggestion of running an online
>>> spreadsheet
>>> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
>>> describe the state of proposals that are in our active purview.  That is,
>>> I'm not proposing to show proposals that are under discussion by the
>>> community, or accepted etc -- just the ones that are in our inbox, *where
>>> the next action is ours.*
>>>
>>> That makes it much easier to see our current inbox, without looking back
>>> for Jocahim's last email and then adding deltas for all the emails since --
>>> which I cannot do in my head.
>>>
>>> Specifically, I have *a column for each committee member's vote. * That
>>> should make it easy for the shepherd to see who is yet to express an
>>> opinion, which I always find difficult.
>>>
>>> As I say above, I am very uncomfortable with "silence means assent" for
>>> any but the smallest proposals.  *I suggest instead that if there is a
>>> proposal where you feel unable to offer an opinion, due to lack of
>>> expertise, or lack of time, you can say "recuse" meaning that you
>>> explicitly want to stand down from this particular proposal.*
>>> (Somehow "abstain" carries a connotation of conflict of interest or
>>> something, but it amounts to the same thing.)  If you are too  under water
>>> to even recuse yourself, maybe it's time to step down.
>>>
>>> So in columns F to O we should see explicit responses from every
>>> committee member, in a timely way.
>>>
>>> Joachim doesn't like spreadsheets like this because they can easily get
>>> out of date.  But it must be better than manually trawling email. *And
>>> it is up to each of us (not Joachim) to fill in our own column for
>>> proposals in our inbox.*
>>>
>>> If we don't like it, we can change it.  You all have edit rights.
>>>
>>> I have populated it with data from Joachim's message of 2 Sept, but
>>> there has been some action since then, so shepherds please update it.  This
>>> is not Joachim's task!
>>>
>>> Thanks
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20230911/ca9bb307/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Sep 11 10:12:24 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 11 Sep 2023 11:12:24 +0100
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CANsrgP+rD4NRwUeaQU6AY6cQWs4G_9d-g5MOiaUosAcb4Ypwfw@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
 <CAKfdd-yFJo=5XPqnZuZWAhaekQEPVXnGS5y0KUM0HWtRp6LRxQ@mail.gmail.com>
 <CANsrgP+NZTacyK-k9K7A4L04b5YuRStRSLLx47ffC8Mv_7rR3w@mail.gmail.com>
 <CANsrgP+rD4NRwUeaQU6AY6cQWs4G_9d-g5MOiaUosAcb4Ypwfw@mail.gmail.com>
Message-ID: <CAJKmMz_uHyAvVdUtoD8Rt+2HsoMO9LySj9EosKC4Kt+zrtfnTw@mail.gmail.com>

>
> One disadvantage of the spreadsheet is that it's not as transparent as the
> other mechanisms we use for this committee (email and github). It should
> probably be visible to all and linked from the docs on github?
>

I wasn't really suggesting that a committee member can say absolutely
nothing, and simply update the spreadsheet with their vote; rather, they
should say (as now, by email) "I support" or "I am lukewarm but will not
stand in the way" or "I don't like this" -- or (new) "I recuse myself".
But in addition take 30s to record that result in the spreadsheet.

In short, zero impact on transparency.  All I'm after is a way to see the
status quo on one page, rather than by composing a zillion deltas.

Simon


On Mon, 11 Sept 2023 at 10:48, Simon Marlow <marlowsd at gmail.com> wrote:

> On Mon, 11 Sept 2023 at 10:46, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I think Simon intends the spreadsheet to be the source of truth for votes
>> by committee members, because he wanted something more explicit than just
>> silence to indicate "I have no strong views on this proposal". FWIW I think
>> it's reasonable to expect *some* action by committee members for each
>> proposal. I'm not wildly enthusiastic about the spreadsheet because it's
>> another thing separate from github and email, and it's a bit manual for my
>> liking, but happy to go with it if that's what people want.
>>
>> One disadvantage of the spreadsheet is that it's not as transparent as
>> the other mechanisms we use for this committee (email and It should
>> probably be visible to all and linked from the docs on github?
>>
>
> That should have read:
>
> One disadvantage of the spreadsheet is that it's not as transparent as the
> other mechanisms we use for this committee (email and github). It should
> probably be visible to all and linked from the docs on github?
>
>
>>
>> Cheers
>> Simon
>>
>> On Sun, 10 Sept 2023 at 03:36, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Simon,
>>>
>>> I think this is a good idea!  Is my understanding correct that this is
>>> for record keeping by the shepherd only? It is not sufficient for steering
>>> committee members to go over the proposal and just fill out
>>> accept/reject/recuse in their respective column? Emails are still the
>>> authorative events?
>>>
>>> Cheers,
>>>   Moritz
>>>
>>> On Sun, 10 Sep 2023 at 10:07 AM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> Dear GHC steering committee
>>>>
>>>> Re GHC proposals I was talking to Simon M about
>>>>
>>>>    - Making the shepherd's job easier and quicker
>>>>    - Providing a way for members of the committee to say (explicitly)
>>>>    "I don't have an opinion about this proposal" and thus recuse themselves.
>>>>    Explicit recusal is better than "silence means assent" because silence can,
>>>>    and often does, mean "I'm under water and not listening".
>>>>
>>>> With that in mind, I want to revive my suggestion of running an online
>>>> spreadsheet
>>>> <https://docs.google.com/spreadsheets/d/1e6GdwHmAjeDEUhTvP-b18MDkpTfH3SMHhFu5F3nDIWc/edit?usp=sharing>to
>>>> describe the state of proposals that are in our active purview.  That is,
>>>> I'm not proposing to show proposals that are under discussion by the
>>>> community, or accepted etc -- just the ones that are in our inbox, *where
>>>> the next action is ours.*
>>>>
>>>> That makes it much easier to see our current inbox, without looking
>>>> back for Jocahim's last email and then adding deltas for all the emails
>>>> since -- which I cannot do in my head.
>>>>
>>>> Specifically, I have *a column for each committee member's vote. *
>>>> That should make it easy for the shepherd to see who is yet to express an
>>>> opinion, which I always find difficult.
>>>>
>>>> As I say above, I am very uncomfortable with "silence means assent" for
>>>> any but the smallest proposals.  *I suggest instead that if there is a
>>>> proposal where you feel unable to offer an opinion, due to lack of
>>>> expertise, or lack of time, you can say "recuse" meaning that you
>>>> explicitly want to stand down from this particular proposal.*
>>>> (Somehow "abstain" carries a connotation of conflict of interest or
>>>> something, but it amounts to the same thing.)  If you are too  under water
>>>> to even recuse yourself, maybe it's time to step down.
>>>>
>>>> So in columns F to O we should see explicit responses from every
>>>> committee member, in a timely way.
>>>>
>>>> Joachim doesn't like spreadsheets like this because they can easily get
>>>> out of date.  But it must be better than manually trawling email. *And
>>>> it is up to each of us (not Joachim) to fill in our own column for
>>>> proposals in our inbox.*
>>>>
>>>> If we don't like it, we can change it.  You all have edit rights.
>>>>
>>>> I have populated it with data from Joachim's message of 2 Sept, but
>>>> there has been some action since then, so shepherds please update it.  This
>>>> is not Joachim's task!
>>>>
>>>> Thanks
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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/20230911/efe66d7f/attachment.html>

From mail at joachim-breitner.de  Mon Sep 11 19:25:15 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 11 Sep 2023 21:25:15 +0200
Subject: [ghc-steering-committee]  Please review #571: -Wsevere,
 Shepherd: Adam
Message-ID: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>

Dear Committee,

based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
warning group -Wsevere for on-by-defaults, error-by-default warnings,
and initially fill it with missing-methods and missing-fields.


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

https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst

I’d like to nominate Adam as the shepherd, who already reviewed it a
bit on Github.

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


Cheers,
Joachim



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


From marlowsd at gmail.com  Tue Sep 12 07:26:30 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 12 Sep 2023 08:26:30 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
Message-ID: <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>

Looks to me like it would be a breaking change even when the extension is
not enabled, because the grammar is not conditional on extensions. The
usual trick of using keywords to enable extensions (because keywords can be
conditionally enabled in the lexer) doesn't work in this case.

Cheers
Simon

On Sun, 10 Sept 2023 at 05:17, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Joachim,
>
> My understand if the cost and drawbacks section[1], is that existing code
> breaks even without explicitly enabling the extension. If this is indeed
> not the case it should be called our explicitly in the section that
> breakage requires the extension to be enabled. Also an explanation why the
> patsyn test cases fail. Do we automatically enable that extension in the
> testsuite? Where does the regression come from?
>
> Maybe I’m misreading that section and it just needs to be clarified that
> there is _no breakage without **explixitly** enabling the extension_ to
> existing code.
>
> Cheers,
>  Moritz
>
> [1]:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>
> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Hi,
>>
>> since this is guarded by an extension that doesn't even exist yet, no
>> code is broken, is there?
>>
>> I also don't expect this to be enabled in the future without coinciding
>> with an intentional action by the developers - enabling this extension or
>> switching to a future language edition that has this enabled by default
>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>> with this change?
>>
>> (That said, we could say that a unparenthized type annotation on a
>> pattern synonym is simply confusing, and thus use a warning to nudge the
>> developers to add the parentheses now.)
>>
>> So not opposed to an early warning, I just don't think it's strictly
>> necessary for this change.
>>
>> Cheers,
>> Joachim
>>
>> _______________________________________________
>> 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/20230912/36a67ab7/attachment.html>

From chris at chrisdornan.com  Tue Sep 12 09:31:04 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 12 Sep 2023 10:31:04 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <CAJKmMz-ztnFvZuZ2S5iqpEHZwXuCA2-MiyKuTyDyOeGq+FGyTA@mail.gmail.com>
 <CAHZ0NLpiu0wwtce_Uw+snCFPCgwbdhSE7t2Vb033PJTJ4vAgWA@mail.gmail.com>
 <d645caf0-0f38-490a-3b8c-53eaec49fd51@well-typed.com>
 <CAKfdd-yMiHABzKREnyra8TGCPe49LhVgL8qq0Fp_045=tHEu9w@mail.gmail.com>
 <5deb3358-0fc1-4b8f-af8d-dfe5eb3d59d9@joachim-breitner.de>
 <CAKfdd-zZNQj5LYOJYbZ8TXwvRHMxTvTiUPABd4w5dqF+gBnntA@mail.gmail.com>
 <CANsrgPJsT3qwCwwgaOMPTxzY-FMhcEP2bh-C8mpTU++T1QeC4g@mail.gmail.com>
Message-ID: <CABSB5jVPUWxYU2OxnnycFF_3C8mPavn2LH-9uD2n2dWSRC2piA@mail.gmail.com>

Exactly -- sorry, I should have picked this up at the start — my bad.

we are exploring non disruptive options in the thread thread on the PR




On 12 Sep 2023, at 08:26, Simon Marlow <marlowsd at gmail.com> wrote:

Looks to me like it would be a breaking change even when the extension is
not enabled, because the grammar is not conditional on extensions. The
usual trick of using keywords to enable extensions (because keywords can be
conditionally enabled in the lexer) doesn't work in this case.

Cheers
Simon

On Sun, 10 Sept 2023 at 05:17, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Joachim,
>
> My understand if the cost and drawbacks section[1], is that existing code
> breaks even without explicitly enabling the extension. If this is indeed
> not the case it should be called our explicitly in the section that
> breakage requires the extension to be enabled. Also an explanation why the
> patsyn test cases fail. Do we automatically enable that extension in the
> testsuite? Where does the regression come from?
>
> Maybe I’m misreading that section and it just needs to be clarified that
> there is _no breakage without **explixitly** enabling the extension_ to
> existing code.
>
> Cheers,
>  Moritz
>
> [1]:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst#costs-and-drawbacks
>
> On Sun, 10 Sep 2023 at 12:04 PM, Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
>> Hi,
>>
>> since this is guarded by an extension that doesn't even exist yet, no
>> code is broken, is there?
>>
>> I also don't expect this to be enabled in the future without coinciding
>> with an intentional action by the developers - enabling this extension or
>> switching to a future language edition that has this enabled by default
>> (should that ever exist). Is it not sufficient if they are _then_ bothered
>> with this change?
>>
>> (That said, we could say that a unparenthized type annotation on a
>> pattern synonym is simply confusing, and thus use a warning to nudge the
>> developers to add the parentheses now.)
>>
>> So not opposed to an early warning, I just don't think it's strictly
>> necessary for this change.
>>
>> Cheers,
>> Joachim
>>
>> _______________________________________________
>> 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/20230912/f917e0da/attachment.html>

From mail at joachim-breitner.de  Wed Sep 13 09:42:26 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 13 Sep 2023 11:42:26 +0200
Subject: [ghc-steering-committee] GHC steering committee status
In-Reply-To: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
References: <CAJKmMz8P-YwtMmB8X3q3GBs6bn+VG2TwZByvN-HiO+ACc-0FHg@mail.gmail.com>
Message-ID: <d8bc9537788ce840b59ea7be80f5a0b6088dce74.camel@joachim-breitner.de>

Hi,

it’s good to keep refining the process! I guess there are actually two
main points in Simon’s mail, and the introduction of a voting sheet is
maybe the less significant; the more important one being that our
process tailored around “silence is assent” does not not work well
enough.

As much as I like the efficiency of that, compared to proper voting, it
only works if we have confidence that every proposal and shepherd
recommendation is still read carefully enough by enough committee
members – and that confidence is lacking.

So gaining a bit more transparency into this, for example via the
spreadsheet, is a good thing. So let’s try that.


There might be more refinements and innovations to our committee
process that would be possible. For example, it would be really great
if someone™ would automate what can be automated, i.e. write something
that uses the Github API to list the statuses, maybe send out reminder
messages/emails, maybe have a web page for voting etc. Or, thinking
non-technically, a more reliable status update frequency and more
aggressive nudging by the secretary.

That said, I find that I don’t have the motivation to do that, and
while I am content to keep doing the mechanic parts of being secretary,
it would probably be good if someone with fresh energy and ideas would
take over the driver’s seat here. So if you have always thought you’d
really like to play this role (or there is someone else you’d want to
try to talk into), don’t hesitate!


Cheers,
Joachim


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


From adam at well-typed.com  Thu Sep 14 08:32:47 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 14 Sep 2023 09:32:47 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
Message-ID: <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>

Dear Committee,

Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods 
and -Wmissing-fields warnings into errors by default (retaining the 
option to downgrade them). I recommend we accept the proposal.

Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
Rendered: 
https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst

This is primarily motivated by the fact that when classes have default 
methods, missing methods can lead to runtime loops, which are generally 
difficult to debug. Since in practice not all users pay attention to 
warnings that do not inhibit compilation, it makes sense to identify a 
class of warnings that are sufficiently serious to require explicit 
action from the user to silence them.

Since these warnings are currently not errors by default, library 
authors experimentally assessing the impact of changes may be lead to 
assume that introducing new methods/fields does not lead to breakage 
(because downstream code will still compile). The proposal thus makes it 
more obvious that adding a new method or field is a breaking change.

The proposal deliberately causes builds to fail by default for some 
libraries that currently emit warnings. Oleg has kindly performed impact 
assessments to identify such libraries, and the breakage of a few 
packages seems worth the cost.

It is easy to restore the warnings to their previous classification by 
passing an option at build time, e.g. using -Wno-error=missing-methods. 
Users can set such an option in cabal.project or stack.yaml to work 
around breakage that is not promptly fixed by the library author.

This change does mean that GHC with -XHaskell98/2010 will by default 
reject some programs that are explicitly permitted by the Haskell98/2010 
specification. I recommend we document this infelicity, but accept it, 
as much of the benefit of the proposal is that it applies by default.

The proposal establishes the precedent that some warnings may be treated 
as errors by default, and introduces a warning group -Wsevere to 
classify them. This seems conceptually useful and gives us the option to 
extend the -Wsevere set in the future (e.g. as a final stage of 
deprecation before a feature is removed).

Thoughts?

Adam


On 11/09/2023 20:25, Joachim Breitner wrote:
> Dear Committee,
> 
> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> warning group -Wsevere for on-by-defaults, error-by-default warnings,
> and initially fill it with missing-methods and missing-fields.
> 
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/571
> 
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> 
> I’d like to nominate Adam as the shepherd, who already reviewed it a
> bit on Github.
> 
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> 
> Cheers,
> Joachim


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Thu Sep 14 09:10:09 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 14 Sep 2023 10:10:09 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
Message-ID: <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>

>
> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
> and -Wmissing-fields warnings into errors by default (retaining the
> option to downgrade them)
>

I'm fine with making these errors, provided the impact on library authors
is not too severe.  But this is a breaking change and people will shout at
us.

*Moritz*, on the face of it this is just the kind of thing you dislike --
and yet it makes it much harder to inadvertently create truly nasty bugs.

This doesn't affect the API of base, and so is no in CLC purview, but I'd
quite like to ask their opinion.  What I don't want is for us to accept it,
and then have a firestorm of complaints.  I think the case is strong:
debugging infinite loops is very painful.

The proposal establishes the precedent that some warnings may be treated
> as errors by default
>

This is a funny thing.  A warning that is an error by default is perhaps..
an error?  Or to put it another way, perhaps all errors are just warnings
that are treated as errors by default?

Perhaps this new beast is an error that can be turned into a warning?
(Most errors cannot.)

I'm not arguing against the proposal, just wondering if there is a simpler
way to say this.

Simon



On Thu, 14 Sept 2023 at 09:33, Adam Gundry <adam at well-typed.com> wrote:

> Dear Committee,
>
> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
> and -Wmissing-fields warnings into errors by default (retaining the
> option to downgrade them). I recommend we accept the proposal.
>
> Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
> Rendered:
>
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>
> This is primarily motivated by the fact that when classes have default
> methods, missing methods can lead to runtime loops, which are generally
> difficult to debug. Since in practice not all users pay attention to
> warnings that do not inhibit compilation, it makes sense to identify a
> class of warnings that are sufficiently serious to require explicit
> action from the user to silence them.
>
> Since these warnings are currently not errors by default, library
> authors experimentally assessing the impact of changes may be lead to
> assume that introducing new methods/fields does not lead to breakage
> (because downstream code will still compile). The proposal thus makes it
> more obvious that adding a new method or field is a breaking change.
>
> The proposal deliberately causes builds to fail by default for some
> libraries that currently emit warnings. Oleg has kindly performed impact
> assessments to identify such libraries, and the breakage of a few
> packages seems worth the cost.
>
> It is easy to restore the warnings to their previous classification by
> passing an option at build time, e.g. using -Wno-error=missing-methods.
> Users can set such an option in cabal.project or stack.yaml to work
> around breakage that is not promptly fixed by the library author.
>
> This change does mean that GHC with -XHaskell98/2010 will by default
> reject some programs that are explicitly permitted by the Haskell98/2010
> specification. I recommend we document this infelicity, but accept it,
> as much of the benefit of the proposal is that it applies by default.
>
> The proposal establishes the precedent that some warnings may be treated
> as errors by default, and introduces a warning group -Wsevere to
> classify them. This seems conceptually useful and gives us the option to
> extend the -Wsevere set in the future (e.g. as a final stage of
> deprecation before a feature is removed).
>
> Thoughts?
>
> Adam
>
>
> On 11/09/2023 20:25, Joachim Breitner wrote:
> > Dear Committee,
> >
> > based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> > warning group -Wsevere for on-by-defaults, error-by-default warnings,
> > and initially fill it with missing-methods and missing-fields.
> >
> >
> > https://github.com/ghc-proposals/ghc-proposals/pull/571
> >
> >
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> >
> > I’d like to nominate Adam as the shepherd, who already reviewed it a
> > bit on Github.
> >
> > Please guide us to a conclusion as outlined in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> >
> > Cheers,
> > Joachim
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230914/dafe614e/attachment.html>

From arnaud.spiwack at tweag.io  Mon Sep 18 13:37:36 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 18 Sep 2023 15:37:36 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
Message-ID: <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>

(I'd argue that most errors can be turned into warnings via
-fdefer-type-errors. It's really coarse though.)

When reading the summary, I was anticipating voting against the proposal,
turning warnings into errors by default creates spurious work for package
maintainers. But I think I'm now convinced. Joachim & Oleg's point is that
we want to consider creating additional `-Wsevere` warnings *to not be
backward compatible*. It's an obligation on GHC designers, and on package
maintainers: such change must be considered very carefully and must be
properly documented. If we break compatibility this way, we want to trigger
as many errors as possible, so that packages get fixed (which they almost
certainly need to).

This is the criterion for having a warning be part of `-Wsevere`. And the
two first contestants (missing methods and missing fields) absolutely seem
to fit the bill.

So I'm in favour.

I have no opinion about whether there is a better way to describe the
spectrum of error-to-warning, as per Simon's musing.

I agree that the CLC should be consulted on this, as it also imposes duties
on them.

/Arnaud

On Thu, 14 Sept 2023 at 11:10, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
>> and -Wmissing-fields warnings into errors by default (retaining the
>> option to downgrade them)
>>
>
> I'm fine with making these errors, provided the impact on library authors
> is not too severe.  But this is a breaking change and people will shout at
> us.
>
> *Moritz*, on the face of it this is just the kind of thing you dislike --
> and yet it makes it much harder to inadvertently create truly nasty bugs.
>
> This doesn't affect the API of base, and so is no in CLC purview, but I'd
> quite like to ask their opinion.  What I don't want is for us to accept it,
> and then have a firestorm of complaints.  I think the case is strong:
> debugging infinite loops is very painful.
>
> The proposal establishes the precedent that some warnings may be treated
>> as errors by default
>>
>
> This is a funny thing.  A warning that is an error by default is perhaps..
> an error?  Or to put it another way, perhaps all errors are just warnings
> that are treated as errors by default?
>
> Perhaps this new beast is an error that can be turned into a warning?
> (Most errors cannot.)
>
> I'm not arguing against the proposal, just wondering if there is a simpler
> way to say this.
>
> Simon
>
>
>
> On Thu, 14 Sept 2023 at 09:33, Adam Gundry <adam at well-typed.com> wrote:
>
>> Dear Committee,
>>
>> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods
>> and -Wmissing-fields warnings into errors by default (retaining the
>> option to downgrade them). I recommend we accept the proposal.
>>
>> Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
>> Rendered:
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>
>> This is primarily motivated by the fact that when classes have default
>> methods, missing methods can lead to runtime loops, which are generally
>> difficult to debug. Since in practice not all users pay attention to
>> warnings that do not inhibit compilation, it makes sense to identify a
>> class of warnings that are sufficiently serious to require explicit
>> action from the user to silence them.
>>
>> Since these warnings are currently not errors by default, library
>> authors experimentally assessing the impact of changes may be lead to
>> assume that introducing new methods/fields does not lead to breakage
>> (because downstream code will still compile). The proposal thus makes it
>> more obvious that adding a new method or field is a breaking change.
>>
>> The proposal deliberately causes builds to fail by default for some
>> libraries that currently emit warnings. Oleg has kindly performed impact
>> assessments to identify such libraries, and the breakage of a few
>> packages seems worth the cost.
>>
>> It is easy to restore the warnings to their previous classification by
>> passing an option at build time, e.g. using -Wno-error=missing-methods.
>> Users can set such an option in cabal.project or stack.yaml to work
>> around breakage that is not promptly fixed by the library author.
>>
>> This change does mean that GHC with -XHaskell98/2010 will by default
>> reject some programs that are explicitly permitted by the Haskell98/2010
>> specification. I recommend we document this infelicity, but accept it,
>> as much of the benefit of the proposal is that it applies by default.
>>
>> The proposal establishes the precedent that some warnings may be treated
>> as errors by default, and introduces a warning group -Wsevere to
>> classify them. This seems conceptually useful and gives us the option to
>> extend the -Wsevere set in the future (e.g. as a final stage of
>> deprecation before a feature is removed).
>>
>> Thoughts?
>>
>> Adam
>>
>>
>> On 11/09/2023 20:25, Joachim Breitner wrote:
>> > Dear Committee,
>> >
>> > based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
>> > warning group -Wsevere for on-by-defaults, error-by-default warnings,
>> > and initially fill it with missing-methods and missing-fields.
>> >
>> >
>> > https://github.com/ghc-proposals/ghc-proposals/pull/571
>> >
>> >
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>> >
>> > I’d like to nominate Adam as the shepherd, who already reviewed it a
>> > bit on Github.
>> >
>> > Please guide us to a conclusion as outlined in
>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> >
>> > Cheers,
>> > Joachim
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230918/c2e1853e/attachment.html>

From mail at joachim-breitner.de  Mon Sep 18 16:11:34 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 18 Sep 2023 18:11:34 +0200
Subject: [ghc-steering-committee] Template too large, removed direct link
Message-ID: <b0b49acd9660c590d84f0d52c5c83741c9fb1e92.camel@joachim-breitner.de>

Hi,

we used to have a direct link in our README to start a new template
pre-filled with the template, but that only worked as long as our
template text was short enough to fit into an URL, and would just give
an error message now. 

I have removed that from the README for now. It requires proposal
authors to understand enough git to know how to create a new file and
copy some other file into it. Maybe not too high a hurdle.

We can add the link back if we have shrunk our template to a sensible
size again… these things grow like nothing else, besides maybe
bureaucracy. If someone makes a heroic effort to make the template more
concise without losing anything important (I think the endorsement
section can go as it is unused, but that alone is not enough), that
would be great!

Cheers,
Joachim

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


From lists at richarde.dev  Mon Sep 18 19:28:20 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 18 Sep 2023 19:28:20 +0000
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
Message-ID: <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>

I'm tentatively in favor here.

* I really want this!

* I'm worried about backward compatibility. I'm pretty sure I've seen an idiom where you have

> data R a = Mk
>   { f1 :: Int
>   , f2 :: Bool
>   , f3 :: a
>   }
> 
> deflt :: forall a. R a
> deflt = { f1 = 42, f2 = False }

and then override f3 via a record update. Of course, a function would work better, but we don't always get "better".

Along similar lines, I can easily imagine

> instance Num Nat where
>   (+) = ...
>   (*) = ...
>   -- no negate or abs

If the programmer were to implement negate, say, the implementation would just be a call to error, so why even bother when GHC helpfully supplies that implementation for you? Again, this isn't the way I would do it, but it's not absurd.

Bottom line for me: I think we should implement and then experiment. Given the potentially delicate nature of this, I might even advocate for implementing this in a release branch, so that as much of Hackage as possible actually has a hope of compiling. Then test to see where the breakage occurs. If were happy with the result, rebase the implementation on master. But I don't want us to get into a state where we accept, implement, observe moderate breakage, and then blast ahead because the committee approved the idea.

Richard

PS: Next additions to -Wsevere: type-errors (replacing -fdefer-type-errors), out-of-scope-errors (replacing -fdefer-scope-errors), partial-type-signatures (replacing -XPartialTypeSignatures), and maybe even derive-functor and friends (replacing -XDeriveFunctor). All of this can be done entirely backward-compatibly!

> On Sep 18, 2023, at 9:37 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> (I'd argue that most errors can be turned into warnings via -fdefer-type-errors. It's really coarse though.)
> 
> When reading the summary, I was anticipating voting against the proposal, turning warnings into errors by default creates spurious work for package maintainers. But I think I'm now convinced. Joachim & Oleg's point is that we want to consider creating additional `-Wsevere` warnings *to not be backward compatible*. It's an obligation on GHC designers, and on package maintainers: such change must be considered very carefully and must be properly documented. If we break compatibility this way, we want to trigger as many errors as possible, so that packages get fixed (which they almost certainly need to).
> 
> This is the criterion for having a warning be part of `-Wsevere`. And the two first contestants (missing methods and missing fields) absolutely seem to fit the bill.
> 
> So I'm in favour.
> 
> I have no opinion about whether there is a better way to describe the spectrum of error-to-warning, as per Simon's musing.
> 
> I agree that the CLC should be consulted on this, as it also imposes duties on them.
> 
> /Arnaud
> 
> On Thu, 14 Sept 2023 at 11:10, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods 
> and -Wmissing-fields warnings into errors by default (retaining the 
> option to downgrade them)
> 
> I'm fine with making these errors, provided the impact on library authors is not too severe.  But this is a breaking change and people will shout at us. 
> 
> Moritz, on the face of it this is just the kind of thing you dislike -- and yet it makes it much harder to inadvertently create truly nasty bugs.
> 
> This doesn't affect the API of base, and so is no in CLC purview, but I'd quite like to ask their opinion.  What I don't want is for us to accept it, and then have a firestorm of complaints.  I think the case is strong: debugging infinite loops is very painful.
> 
> The proposal establishes the precedent that some warnings may be treated 
> as errors by default
> 
> This is a funny thing.  A warning that is an error by default is perhaps.. an error?  Or to put it another way, perhaps all errors are just warnings that are treated as errors by default?
> 
> Perhaps this new beast is an error that can be turned into a warning?   (Most errors cannot.)
> 
> I'm not arguing against the proposal, just wondering if there is a simpler way to say this.
> 
> Simon
> 
> 
> 
> On Thu, 14 Sept 2023 at 09:33, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> Dear Committee,
> 
> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods 
> and -Wmissing-fields warnings into errors by default (retaining the 
> option to downgrade them). I recommend we accept the proposal.
> 
> Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
> Rendered: 
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
> 
> This is primarily motivated by the fact that when classes have default 
> methods, missing methods can lead to runtime loops, which are generally 
> difficult to debug. Since in practice not all users pay attention to 
> warnings that do not inhibit compilation, it makes sense to identify a 
> class of warnings that are sufficiently serious to require explicit 
> action from the user to silence them.
> 
> Since these warnings are currently not errors by default, library 
> authors experimentally assessing the impact of changes may be lead to 
> assume that introducing new methods/fields does not lead to breakage 
> (because downstream code will still compile). The proposal thus makes it 
> more obvious that adding a new method or field is a breaking change.
> 
> The proposal deliberately causes builds to fail by default for some 
> libraries that currently emit warnings. Oleg has kindly performed impact 
> assessments to identify such libraries, and the breakage of a few 
> packages seems worth the cost.
> 
> It is easy to restore the warnings to their previous classification by 
> passing an option at build time, e.g. using -Wno-error=missing-methods. 
> Users can set such an option in cabal.project or stack.yaml to work 
> around breakage that is not promptly fixed by the library author.
> 
> This change does mean that GHC with -XHaskell98/2010 will by default 
> reject some programs that are explicitly permitted by the Haskell98/2010 
> specification. I recommend we document this infelicity, but accept it, 
> as much of the benefit of the proposal is that it applies by default.
> 
> The proposal establishes the precedent that some warnings may be treated 
> as errors by default, and introduces a warning group -Wsevere to 
> classify them. This seems conceptually useful and gives us the option to 
> extend the -Wsevere set in the future (e.g. as a final stage of 
> deprecation before a feature is removed).
> 
> Thoughts?
> 
> Adam
> 
> 
> On 11/09/2023 20:25, Joachim Breitner wrote:
> > Dear Committee,
> > 
> > based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
> > warning group -Wsevere for on-by-defaults, error-by-default warnings,
> > and initially fill it with missing-methods and missing-fields.
> > 
> > 
> > https://github.com/ghc-proposals/ghc-proposals/pull/571 <https://github.com/ghc-proposals/ghc-proposals/pull/571>
> > 
> > https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst <https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst>
> > 
> > I’d like to nominate Adam as the shepherd, who already reviewed it a
> > bit on Github.
> > 
> > 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>
> > 
> > 
> > Cheers,
> > Joachim
> 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
> 
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> 
> _______________________________________________
> 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>
> 
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>.
> _______________________________________________
> 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/20230918/e5d890f7/attachment-0001.html>

From adam at well-typed.com  Tue Sep 19 07:14:46 2023
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 19 Sep 2023 08:14:46 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
Message-ID: <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>

On 18/09/2023 20:28, Richard Eisenberg wrote:
>
> Bottom line for me: I think we should implement and then experiment. 
> Given the potentially delicate nature of this, I might even advocate for 
> implementing this in a release branch, so that as much of Hackage as 
> possible actually has a hope of compiling. Then test to see where the 
> breakage occurs. If were happy with the result, rebase the 
> implementation on master. But I don't want us to get into a state where 
> we accept, implement, observe moderate breakage, and then blast ahead 
> because the committee approved the idea.

The breakage concern is worth thinking about, I agree, but fortunately 
in this instance we don't need to wait for an implementation to run an 
experiment. The change can be relatively effectively simulated by 
compiling with -Werror=missing-methods -Werror=missing-fields, and 
indeed Oleg has done so already for clc-stackage as he reports here:

https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536

https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737

Out of nearly 3000 packages, he found 22 were broken by 
-Werror=missing-methods and 9 by -Werror=missing-fields.

Adam


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From moritz.angermann at gmail.com  Tue Sep 19 07:52:57 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 19 Sep 2023 15:52:57 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
Message-ID: <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>

Just to clarify: I am not against change, or evolution.  I'm actually
looking forward to progress. What I am against ist sudden breakage.
As such, if there _is_ breakage (clc stackage is a subset), we have to
assume there will be breakage in production codebases, most
of which are likely not public.

Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
`-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
Advertise this prominently in the release notes for GHC 9.10? And then
enable this fully in GHC 9.14? Though I guess the flag we want
is really `-Wcompat-error`, or we rather change the notion of -Wcompat to
also promote warnings to errors early? In any case either the
current documentation for -Wcompat would need to be adjusted, or we'd need
something that signals new errors.

Ideally I'd like to see something like a warning for `missing-methods`,
with an additional note that this will become an error in GHC X.Y,
and that one can opt into this behaviour by enabling -Wcompat.

My test for support is generally: can I take existing code unmodified, swap
out the compiler, and it will still compile? That way I can report
back regressions, bugs, ... early on during alphas, betas, and release
candidates. Right now I can't. I usually have to wait for x.y.4+. That
also means the feedback for anyone working on GHC is terrible. You won't
hear about bugs until late in the release cycle where the
master branch has moved forward by a lot. At the same time it's painful for
integrators who end up having to backport and patch old
branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
states anything but 9.4 and 9.6 won't see any further releases.
Our current production compiler is 8.10, we could not switch to 9.2 due to
performance regressions. And finally have almost everything
compiling with 9.6, but are far from having any form of performance profile
feedback on 9.6 yet.

Again, I'm not against breakage per-se. I'm against sudden breakage.
Managed evolution or however we want to call it, is something
I'd absolutely support!

Best,
 Moritz

On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:

> On 18/09/2023 20:28, Richard Eisenberg wrote:
> >
> > Bottom line for me: I think we should implement and then experiment.
> > Given the potentially delicate nature of this, I might even advocate for
> > implementing this in a release branch, so that as much of Hackage as
> > possible actually has a hope of compiling. Then test to see where the
> > breakage occurs. If were happy with the result, rebase the
> > implementation on master. But I don't want us to get into a state where
> > we accept, implement, observe moderate breakage, and then blast ahead
> > because the committee approved the idea.
>
> The breakage concern is worth thinking about, I agree, but fortunately
> in this instance we don't need to wait for an implementation to run an
> experiment. The change can be relatively effectively simulated by
> compiling with -Werror=missing-methods -Werror=missing-fields, and
> indeed Oleg has done so already for clc-stackage as he reports here:
>
> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>
>
> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>
> Out of nearly 3000 packages, he found 22 were broken by
> -Werror=missing-methods and 9 by -Werror=missing-fields.
>
> Adam
>
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230919/7b19b56b/attachment.html>

From marlowsd at gmail.com  Tue Sep 19 13:20:14 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 19 Sep 2023 14:20:14 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
Message-ID: <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>

For those not aware, Hackage right now rejects packages with `-Wall
-Werror` in their ghc-options because warnings change between GHC versions
so this tends to lead to unnecessary breakage. I think that's a good
policy, even though I use `-Wall -Werror` everywhere when developing.

Interestingly, this proposal creates exactly the same kind of risk, by
making some existing warnings errors by default and introducing the
possibility that the set of warnings treated this way might change in the
future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
a risk for developers.

Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
programs, unless you also say `-Wwarn=severe`. We are normally careful to
document the ways in which GHC deviates from the language definition in the
user guide.

I can see the motivation, but I have to vote against here. I don't think we
should change the set of programs accepted by the compiler unless
absolutely necessary. If it's legal code today, it should be accepted by
future versions of the compiler unless we have a really good reason to
change that.

Cheers
Simon


On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Just to clarify: I am not against change, or evolution.  I'm actually
> looking forward to progress. What I am against ist sudden breakage.
> As such, if there _is_ breakage (clc stackage is a subset), we have to
> assume there will be breakage in production codebases, most
> of which are likely not public.
>
> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
> Advertise this prominently in the release notes for GHC 9.10? And then
> enable this fully in GHC 9.14? Though I guess the flag we want
> is really `-Wcompat-error`, or we rather change the notion of -Wcompat to
> also promote warnings to errors early? In any case either the
> current documentation for -Wcompat would need to be adjusted, or we'd need
> something that signals new errors.
>
> Ideally I'd like to see something like a warning for `missing-methods`,
> with an additional note that this will become an error in GHC X.Y,
> and that one can opt into this behaviour by enabling -Wcompat.
>
> My test for support is generally: can I take existing code unmodified,
> swap out the compiler, and it will still compile? That way I can report
> back regressions, bugs, ... early on during alphas, betas, and release
> candidates. Right now I can't. I usually have to wait for x.y.4+. That
> also means the feedback for anyone working on GHC is terrible. You won't
> hear about bugs until late in the release cycle where the
> master branch has moved forward by a lot. At the same time it's painful
> for integrators who end up having to backport and patch old
> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
> states anything but 9.4 and 9.6 won't see any further releases.
> Our current production compiler is 8.10, we could not switch to 9.2 due to
> performance regressions. And finally have almost everything
> compiling with 9.6, but are far from having any form of performance
> profile feedback on 9.6 yet.
>
> Again, I'm not against breakage per-se. I'm against sudden breakage.
> Managed evolution or however we want to call it, is something
> I'd absolutely support!
>
> Best,
>  Moritz
>
> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:
>
>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>> >
>> > Bottom line for me: I think we should implement and then experiment.
>> > Given the potentially delicate nature of this, I might even advocate
>> for
>> > implementing this in a release branch, so that as much of Hackage as
>> > possible actually has a hope of compiling. Then test to see where the
>> > breakage occurs. If were happy with the result, rebase the
>> > implementation on master. But I don't want us to get into a state where
>> > we accept, implement, observe moderate breakage, and then blast ahead
>> > because the committee approved the idea.
>>
>> The breakage concern is worth thinking about, I agree, but fortunately
>> in this instance we don't need to wait for an implementation to run an
>> experiment. The change can be relatively effectively simulated by
>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>> indeed Oleg has done so already for clc-stackage as he reports here:
>>
>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>
>> Out of nearly 3000 packages, he found 22 were broken by
>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>
>> Adam
>>
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230919/e59f5ed9/attachment.html>

From chris at chrisdornan.com  Tue Sep 19 13:35:14 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 19 Sep 2023 14:35:14 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
Message-ID: <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>

Like Simon M I habitually develop with -Wall -Werror, and like Moritz I think we really need to be very careful about deliberately breaking packages.

For sure, if we were starting anew I would be be sympathetic to treating them as errors, but, for me, that isn't a good enough reason to make this breaking change.

For this reason I vote against this proposal. 

Chris

> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> For those not aware, Hackage right now rejects packages with `-Wall -Werror` in their ghc-options because warnings change between GHC versions so this tends to lead to unnecessary breakage. I think that's a good policy, even though I use `-Wall -Werror` everywhere when developing.
> 
> Interestingly, this proposal creates exactly the same kind of risk, by making some existing warnings errors by default and introducing the possibility that the set of warnings treated this way might change in the future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still a risk for developers.
> 
> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010 programs, unless you also say `-Wwarn=severe`. We are normally careful to document the ways in which GHC deviates from the language definition in the user guide.
> 
> I can see the motivation, but I have to vote against here. I don't think we should change the set of programs accepted by the compiler unless absolutely necessary. If it's legal code today, it should be accepted by future versions of the compiler unless we have a really good reason to change that.
> 
> Cheers
> Simon
> 
> 
> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> Just to clarify: I am not against change, or evolution.  I'm actually looking forward to progress. What I am against ist sudden breakage.
>> As such, if there _is_ breakage (clc stackage is a subset), we have to assume there will be breakage in production codebases, most
>> of which are likely not public.
>> 
>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>> Advertise this prominently in the release notes for GHC 9.10? And then enable this fully in GHC 9.14? Though I guess the flag we want
>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat to also promote warnings to errors early? In any case either the
>> current documentation for -Wcompat would need to be adjusted, or we'd need something that signals new errors.
>> 
>> Ideally I'd like to see something like a warning for `missing-methods`, with an additional note that this will become an error in GHC X.Y,
>> and that one can opt into this behaviour by enabling -Wcompat.
>> 
>> My test for support is generally: can I take existing code unmodified, swap out the compiler, and it will still compile? That way I can report
>> back regressions, bugs, ... early on during alphas, betas, and release candidates. Right now I can't. I usually have to wait for x.y.4+. That
>> also means the feedback for anyone working on GHC is terrible. You won't hear about bugs until late in the release cycle where the
>> master branch has moved forward by a lot. At the same time it's painful for integrators who end up having to backport and patch old
>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already states anything but 9.4 and 9.6 won't see any further releases.
>> Our current production compiler is 8.10, we could not switch to 9.2 due to performance regressions. And finally have almost everything
>> compiling with 9.6, but are far from having any form of performance profile feedback on 9.6 yet.
>> 
>> Again, I'm not against breakage per-se. I'm against sudden breakage. Managed evolution or however we want to call it, is something
>> I'd absolutely support!
>> 
>> Best,
>>  Moritz
>> 
>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>> >
>>> > Bottom line for me: I think we should implement and then experiment. 
>>> > Given the potentially delicate nature of this, I might even advocate for 
>>> > implementing this in a release branch, so that as much of Hackage as 
>>> > possible actually has a hope of compiling. Then test to see where the 
>>> > breakage occurs. If were happy with the result, rebase the 
>>> > implementation on master. But I don't want us to get into a state where 
>>> > we accept, implement, observe moderate breakage, and then blast ahead 
>>> > because the committee approved the idea.
>>> 
>>> The breakage concern is worth thinking about, I agree, but fortunately 
>>> in this instance we don't need to wait for an implementation to run an 
>>> experiment. The change can be relatively effectively simulated by 
>>> compiling with -Werror=missing-methods -Werror=missing-fields, and 
>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>> 
>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>> 
>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>> 
>>> Out of nearly 3000 packages, he found 22 were broken by 
>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>> 
>>> Adam
>>> 
>>> 
>>> -- 
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>> 
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> 
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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/20230919/09f5df75/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Sep 19 14:26:33 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 19 Sep 2023 15:26:33 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
Message-ID: <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>

I think that the motivation for this proposal is to make it harder to shoot
yourself in the foot.

Maybe implementing this "severe" *category*, but not changing its *default *to
error, would get us some of the way there?  Then "best-practice guidance"
could be "use -Werror=severe", and job done.  That's a bit easier to say
than saying "use -Werrror=missing-methods -Werror= ..." etc.

Simon

On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com> wrote:

> Like Simon M I habitually develop with -Wall -Werror, and like Moritz I
> think we really need to be very careful about deliberately breaking
> packages.
>
> For sure, if we were starting anew I would be be sympathetic to treating
> them as errors, but, for me, that isn't a good enough reason to make this
> breaking change.
>
> For this reason I vote against this proposal.
>
> Chris
>
> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>
> For those not aware, Hackage right now rejects packages with `-Wall
> -Werror` in their ghc-options because warnings change between GHC versions
> so this tends to lead to unnecessary breakage. I think that's a good
> policy, even though I use `-Wall -Werror` everywhere when developing.
>
> Interestingly, this proposal creates exactly the same kind of risk, by
> making some existing warnings errors by default and introducing the
> possibility that the set of warnings treated this way might change in the
> future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
> a risk for developers.
>
> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
> programs, unless you also say `-Wwarn=severe`. We are normally careful to
> document the ways in which GHC deviates from the language definition in the
> user guide.
>
> I can see the motivation, but I have to vote against here. I don't think
> we should change the set of programs accepted by the compiler unless
> absolutely necessary. If it's legal code today, it should be accepted by
> future versions of the compiler unless we have a really good reason to
> change that.
>
> Cheers
> Simon
>
>
> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> Just to clarify: I am not against change, or evolution.  I'm actually
>> looking forward to progress. What I am against ist sudden breakage.
>> As such, if there _is_ breakage (clc stackage is a subset), we have to
>> assume there will be breakage in production codebases, most
>> of which are likely not public.
>>
>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>> Advertise this prominently in the release notes for GHC 9.10? And then
>> enable this fully in GHC 9.14? Though I guess the flag we want
>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat to
>> also promote warnings to errors early? In any case either the
>> current documentation for -Wcompat would need to be adjusted, or we'd
>> need something that signals new errors.
>>
>> Ideally I'd like to see something like a warning for `missing-methods`,
>> with an additional note that this will become an error in GHC X.Y,
>> and that one can opt into this behaviour by enabling -Wcompat.
>>
>> My test for support is generally: can I take existing code unmodified,
>> swap out the compiler, and it will still compile? That way I can report
>> back regressions, bugs, ... early on during alphas, betas, and release
>> candidates. Right now I can't. I usually have to wait for x.y.4+. That
>> also means the feedback for anyone working on GHC is terrible. You won't
>> hear about bugs until late in the release cycle where the
>> master branch has moved forward by a lot. At the same time it's painful
>> for integrators who end up having to backport and patch old
>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
>> states anything but 9.4 and 9.6 won't see any further releases.
>> Our current production compiler is 8.10, we could not switch to 9.2 due
>> to performance regressions. And finally have almost everything
>> compiling with 9.6, but are far from having any form of performance
>> profile feedback on 9.6 yet.
>>
>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>> Managed evolution or however we want to call it, is something
>> I'd absolutely support!
>>
>> Best,
>>  Moritz
>>
>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>> >
>>> > Bottom line for me: I think we should implement and then experiment.
>>> > Given the potentially delicate nature of this, I might even advocate
>>> for
>>> > implementing this in a release branch, so that as much of Hackage as
>>> > possible actually has a hope of compiling. Then test to see where the
>>> > breakage occurs. If were happy with the result, rebase the
>>> > implementation on master. But I don't want us to get into a state
>>> where
>>> > we accept, implement, observe moderate breakage, and then blast ahead
>>> > because the committee approved the idea.
>>>
>>> The breakage concern is worth thinking about, I agree, but fortunately
>>> in this instance we don't need to wait for an implementation to run an
>>> experiment. The change can be relatively effectively simulated by
>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>
>>> Out of nearly 3000 packages, he found 22 were broken by
>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>
>>> Adam
>>>
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>
>>> _______________________________________________
>>> 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/20230919/988096e3/attachment.html>

From marlowsd at gmail.com  Tue Sep 19 14:31:20 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 19 Sep 2023 15:31:20 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
Message-ID: <CANsrgPKvA2G2Gy+58WehFUvnNwVgbK2Y7qKS5XeSZrUymrWwvw@mail.gmail.com>

On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> I think that the motivation for this proposal is to make it harder to
> shoot yourself in the foot.
>
> Maybe implementing this "severe" *category*, but not changing its *default
> *to error, would get us some of the way there?  Then "best-practice
> guidance" could be "use -Werror=severe", and job done.  That's a bit easier
> to say than saying "use -Werrror=missing-methods -Werror= ..." etc.
>

Absolutely! I'm only objecting to changing the default. Adding the "severe"
category by itself is useful, I agree.

Cheers
Simon


>
> Simon
>
> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> Like Simon M I habitually develop with -Wall -Werror, and like Moritz I
>> think we really need to be very careful about deliberately breaking
>> packages.
>>
>> For sure, if we were starting anew I would be be sympathetic to treating
>> them as errors, but, for me, that isn't a good enough reason to make this
>> breaking change.
>>
>> For this reason I vote against this proposal.
>>
>> Chris
>>
>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> For those not aware, Hackage right now rejects packages with `-Wall
>> -Werror` in their ghc-options because warnings change between GHC versions
>> so this tends to lead to unnecessary breakage. I think that's a good
>> policy, even though I use `-Wall -Werror` everywhere when developing.
>>
>> Interestingly, this proposal creates exactly the same kind of risk, by
>> making some existing warnings errors by default and introducing the
>> possibility that the set of warnings treated this way might change in the
>> future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
>> a risk for developers.
>>
>> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
>> programs, unless you also say `-Wwarn=severe`. We are normally careful to
>> document the ways in which GHC deviates from the language definition in the
>> user guide.
>>
>> I can see the motivation, but I have to vote against here. I don't think
>> we should change the set of programs accepted by the compiler unless
>> absolutely necessary. If it's legal code today, it should be accepted by
>> future versions of the compiler unless we have a really good reason to
>> change that.
>>
>> Cheers
>> Simon
>>
>>
>> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Just to clarify: I am not against change, or evolution.  I'm actually
>>> looking forward to progress. What I am against ist sudden breakage.
>>> As such, if there _is_ breakage (clc stackage is a subset), we have to
>>> assume there will be breakage in production codebases, most
>>> of which are likely not public.
>>>
>>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>>> Advertise this prominently in the release notes for GHC 9.10? And then
>>> enable this fully in GHC 9.14? Though I guess the flag we want
>>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat
>>> to also promote warnings to errors early? In any case either the
>>> current documentation for -Wcompat would need to be adjusted, or we'd
>>> need something that signals new errors.
>>>
>>> Ideally I'd like to see something like a warning for `missing-methods`,
>>> with an additional note that this will become an error in GHC X.Y,
>>> and that one can opt into this behaviour by enabling -Wcompat.
>>>
>>> My test for support is generally: can I take existing code unmodified,
>>> swap out the compiler, and it will still compile? That way I can report
>>> back regressions, bugs, ... early on during alphas, betas, and release
>>> candidates. Right now I can't. I usually have to wait for x.y.4+. That
>>> also means the feedback for anyone working on GHC is terrible. You won't
>>> hear about bugs until late in the release cycle where the
>>> master branch has moved forward by a lot. At the same time it's painful
>>> for integrators who end up having to backport and patch old
>>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status already
>>> states anything but 9.4 and 9.6 won't see any further releases.
>>> Our current production compiler is 8.10, we could not switch to 9.2 due
>>> to performance regressions. And finally have almost everything
>>> compiling with 9.6, but are far from having any form of performance
>>> profile feedback on 9.6 yet.
>>>
>>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>>> Managed evolution or however we want to call it, is something
>>> I'd absolutely support!
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>>> >
>>>> > Bottom line for me: I think we should implement and then experiment.
>>>> > Given the potentially delicate nature of this, I might even advocate
>>>> for
>>>> > implementing this in a release branch, so that as much of Hackage as
>>>> > possible actually has a hope of compiling. Then test to see where the
>>>> > breakage occurs. If were happy with the result, rebase the
>>>> > implementation on master. But I don't want us to get into a state
>>>> where
>>>> > we accept, implement, observe moderate breakage, and then blast ahead
>>>> > because the committee approved the idea.
>>>>
>>>> The breakage concern is worth thinking about, I agree, but fortunately
>>>> in this instance we don't need to wait for an implementation to run an
>>>> experiment. The change can be relatively effectively simulated by
>>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>>
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>>
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>>
>>>> Out of nearly 3000 packages, he found 22 were broken by
>>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>>
>>>> Adam
>>>>
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>
>>>> _______________________________________________
>>>> 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/20230919/15f18f0b/attachment-0001.html>

From chris at chrisdornan.com  Tue Sep 19 15:13:35 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 19 Sep 2023 16:13:35 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPKvA2G2Gy+58WehFUvnNwVgbK2Y7qKS5XeSZrUymrWwvw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <CANsrgPKvA2G2Gy+58WehFUvnNwVgbK2Y7qKS5XeSZrUymrWwvw@mail.gmail.com>
Message-ID: <CABSB5jVKEGSxJxM0Dh78VM+A9r8X1x45pZ_p8LSC+VpV_gUMPw@mail.gmail.com>

My opposition is entirely grounded in the change of default behaviour;
otherwise i am in favour.

On Tue, 19 Sep 2023 at 15:31, Simon Marlow <marlowsd at gmail.com> wrote:

> On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I think that the motivation for this proposal is to make it harder to
>> shoot yourself in the foot.
>>
>> Maybe implementing this "severe" *category*, but not changing its *default
>> *to error, would get us some of the way there?  Then "best-practice
>> guidance" could be "use -Werror=severe", and job done.  That's a bit easier
>> to say than saying "use -Werrror=missing-methods -Werror= ..." etc.
>>
>
> Absolutely! I'm only objecting to changing the default. Adding the
> "severe" category by itself is useful, I agree.
>
> Cheers
> Simon
>
>
>>
>> Simon
>>
>> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com>
>> wrote:
>>
>>> Like Simon M I habitually develop with -Wall -Werror, and like Moritz I
>>> think we really need to be very careful about deliberately breaking
>>> packages.
>>>
>>> For sure, if we were starting anew I would be be sympathetic to treating
>>> them as errors, but, for me, that isn't a good enough reason to make this
>>> breaking change.
>>>
>>> For this reason I vote against this proposal.
>>>
>>> Chris
>>>
>>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>>
>>> For those not aware, Hackage right now rejects packages with `-Wall
>>> -Werror` in their ghc-options because warnings change between GHC versions
>>> so this tends to lead to unnecessary breakage. I think that's a good
>>> policy, even though I use `-Wall -Werror` everywhere when developing.
>>>
>>> Interestingly, this proposal creates exactly the same kind of risk, by
>>> making some existing warnings errors by default and introducing the
>>> possibility that the set of warnings treated this way might change in the
>>> future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
>>> a risk for developers.
>>>
>>> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
>>> programs, unless you also say `-Wwarn=severe`. We are normally careful to
>>> document the ways in which GHC deviates from the language definition in the
>>> user guide.
>>>
>>> I can see the motivation, but I have to vote against here. I don't think
>>> we should change the set of programs accepted by the compiler unless
>>> absolutely necessary. If it's legal code today, it should be accepted by
>>> future versions of the compiler unless we have a really good reason to
>>> change that.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> Just to clarify: I am not against change, or evolution.  I'm actually
>>>> looking forward to progress. What I am against ist sudden breakage.
>>>> As such, if there _is_ breakage (clc stackage is a subset), we have to
>>>> assume there will be breakage in production codebases, most
>>>> of which are likely not public.
>>>>
>>>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>>>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>>>> Advertise this prominently in the release notes for GHC 9.10? And then
>>>> enable this fully in GHC 9.14? Though I guess the flag we want
>>>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat
>>>> to also promote warnings to errors early? In any case either the
>>>> current documentation for -Wcompat would need to be adjusted, or we'd
>>>> need something that signals new errors.
>>>>
>>>> Ideally I'd like to see something like a warning for `missing-methods`,
>>>> with an additional note that this will become an error in GHC X.Y,
>>>> and that one can opt into this behaviour by enabling -Wcompat.
>>>>
>>>> My test for support is generally: can I take existing code unmodified,
>>>> swap out the compiler, and it will still compile? That way I can report
>>>> back regressions, bugs, ... early on during alphas, betas, and release
>>>> candidates. Right now I can't. I usually have to wait for x.y.4+. That
>>>> also means the feedback for anyone working on GHC is terrible. You
>>>> won't hear about bugs until late in the release cycle where the
>>>> master branch has moved forward by a lot. At the same time it's painful
>>>> for integrators who end up having to backport and patch old
>>>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
>>>> already states anything but 9.4 and 9.6 won't see any further releases.
>>>> Our current production compiler is 8.10, we could not switch to 9.2 due
>>>> to performance regressions. And finally have almost everything
>>>> compiling with 9.6, but are far from having any form of performance
>>>> profile feedback on 9.6 yet.
>>>>
>>>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>>>> Managed evolution or however we want to call it, is something
>>>> I'd absolutely support!
>>>>
>>>> Best,
>>>>  Moritz
>>>>
>>>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>>>> >
>>>>> > Bottom line for me: I think we should implement and then experiment.
>>>>> > Given the potentially delicate nature of this, I might even advocate
>>>>> for
>>>>> > implementing this in a release branch, so that as much of Hackage as
>>>>> > possible actually has a hope of compiling. Then test to see where
>>>>> the
>>>>> > breakage occurs. If were happy with the result, rebase the
>>>>> > implementation on master. But I don't want us to get into a state
>>>>> where
>>>>> > we accept, implement, observe moderate breakage, and then blast
>>>>> ahead
>>>>> > because the committee approved the idea.
>>>>>
>>>>> The breakage concern is worth thinking about, I agree, but fortunately
>>>>> in this instance we don't need to wait for an implementation to run an
>>>>> experiment. The change can be relatively effectively simulated by
>>>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>>>
>>>>>
>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>>>
>>>>>
>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>>>
>>>>> Out of nearly 3000 packages, he found 22 were broken by
>>>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> --
>>>>> Adam Gundry, Haskell Consultant
>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>
>>>>> Registered in England & Wales, OC335890
>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>
>>>>> _______________________________________________
>>>>> 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/20230919/55111e05/attachment.html>

From arnaud.spiwack at tweag.io  Tue Sep 19 16:20:44 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 19 Sep 2023 18:20:44 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CABSB5jVKEGSxJxM0Dh78VM+A9r8X1x45pZ_p8LSC+VpV_gUMPw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <CANsrgPKvA2G2Gy+58WehFUvnNwVgbK2Y7qKS5XeSZrUymrWwvw@mail.gmail.com>
 <CABSB5jVKEGSxJxM0Dh78VM+A9r8X1x45pZ_p8LSC+VpV_gUMPw@mail.gmail.com>
Message-ID: <CAGwnsnmWDwh88CbFYTtZaZ=Sn-yC+MYYQT4WbAXMR0u4vxrw2Q@mail.gmail.com>

Is the general consensus on this thread that defaults should never change,
even if better defaults are discovered?

On Tue, 19 Sept 2023 at 17:13, Chris Dornan <chris at chrisdornan.com> wrote:

> My opposition is entirely grounded in the change of default behaviour;
> otherwise i am in favour.
>
> On Tue, 19 Sep 2023 at 15:31, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I think that the motivation for this proposal is to make it harder to
>>> shoot yourself in the foot.
>>>
>>> Maybe implementing this "severe" *category*, but not changing its *default
>>> *to error, would get us some of the way there?  Then "best-practice
>>> guidance" could be "use -Werror=severe", and job done.  That's a bit easier
>>> to say than saying "use -Werrror=missing-methods -Werror= ..." etc.
>>>
>>
>> Absolutely! I'm only objecting to changing the default. Adding the
>> "severe" category by itself is useful, I agree.
>>
>> Cheers
>> Simon
>>
>>
>>>
>>> Simon
>>>
>>> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com>
>>> wrote:
>>>
>>>> Like Simon M I habitually develop with -Wall -Werror, and like Moritz I
>>>> think we really need to be very careful about deliberately breaking
>>>> packages.
>>>>
>>>> For sure, if we were starting anew I would be be sympathetic to
>>>> treating them as errors, but, for me, that isn't a good enough reason to
>>>> make this breaking change.
>>>>
>>>> For this reason I vote against this proposal.
>>>>
>>>> Chris
>>>>
>>>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>>>
>>>> For those not aware, Hackage right now rejects packages with `-Wall
>>>> -Werror` in their ghc-options because warnings change between GHC versions
>>>> so this tends to lead to unnecessary breakage. I think that's a good
>>>> policy, even though I use `-Wall -Werror` everywhere when developing.
>>>>
>>>> Interestingly, this proposal creates exactly the same kind of risk, by
>>>> making some existing warnings errors by default and introducing the
>>>> possibility that the set of warnings treated this way might change in the
>>>> future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
>>>> a risk for developers.
>>>>
>>>> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
>>>> programs, unless you also say `-Wwarn=severe`. We are normally careful to
>>>> document the ways in which GHC deviates from the language definition in the
>>>> user guide.
>>>>
>>>> I can see the motivation, but I have to vote against here. I don't
>>>> think we should change the set of programs accepted by the compiler unless
>>>> absolutely necessary. If it's legal code today, it should be accepted by
>>>> future versions of the compiler unless we have a really good reason to
>>>> change that.
>>>>
>>>> Cheers
>>>> Simon
>>>>
>>>>
>>>> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> Just to clarify: I am not against change, or evolution.  I'm actually
>>>>> looking forward to progress. What I am against ist sudden breakage.
>>>>> As such, if there _is_ breakage (clc stackage is a subset), we have to
>>>>> assume there will be breakage in production codebases, most
>>>>> of which are likely not public.
>>>>>
>>>>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>>>>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>>>>> Advertise this prominently in the release notes for GHC 9.10? And then
>>>>> enable this fully in GHC 9.14? Though I guess the flag we want
>>>>> is really `-Wcompat-error`, or we rather change the notion of -Wcompat
>>>>> to also promote warnings to errors early? In any case either the
>>>>> current documentation for -Wcompat would need to be adjusted, or we'd
>>>>> need something that signals new errors.
>>>>>
>>>>> Ideally I'd like to see something like a warning for
>>>>> `missing-methods`, with an additional note that this will become an error
>>>>> in GHC X.Y,
>>>>> and that one can opt into this behaviour by enabling -Wcompat.
>>>>>
>>>>> My test for support is generally: can I take existing code unmodified,
>>>>> swap out the compiler, and it will still compile? That way I can report
>>>>> back regressions, bugs, ... early on during alphas, betas, and release
>>>>> candidates. Right now I can't. I usually have to wait for x.y.4+. That
>>>>> also means the feedback for anyone working on GHC is terrible. You
>>>>> won't hear about bugs until late in the release cycle where the
>>>>> master branch has moved forward by a lot. At the same time it's
>>>>> painful for integrators who end up having to backport and patch old
>>>>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
>>>>> already states anything but 9.4 and 9.6 won't see any further releases.
>>>>> Our current production compiler is 8.10, we could not switch to 9.2
>>>>> due to performance regressions. And finally have almost everything
>>>>> compiling with 9.6, but are far from having any form of performance
>>>>> profile feedback on 9.6 yet.
>>>>>
>>>>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>>>>> Managed evolution or however we want to call it, is something
>>>>> I'd absolutely support!
>>>>>
>>>>> Best,
>>>>>  Moritz
>>>>>
>>>>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com>
>>>>> wrote:
>>>>>
>>>>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>>>>> >
>>>>>> > Bottom line for me: I think we should implement and then
>>>>>> experiment.
>>>>>> > Given the potentially delicate nature of this, I might even
>>>>>> advocate for
>>>>>> > implementing this in a release branch, so that as much of Hackage
>>>>>> as
>>>>>> > possible actually has a hope of compiling. Then test to see where
>>>>>> the
>>>>>> > breakage occurs. If were happy with the result, rebase the
>>>>>> > implementation on master. But I don't want us to get into a state
>>>>>> where
>>>>>> > we accept, implement, observe moderate breakage, and then blast
>>>>>> ahead
>>>>>> > because the committee approved the idea.
>>>>>>
>>>>>> The breakage concern is worth thinking about, I agree, but
>>>>>> fortunately
>>>>>> in this instance we don't need to wait for an implementation to run
>>>>>> an
>>>>>> experiment. The change can be relatively effectively simulated by
>>>>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>>>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>>>>
>>>>>>
>>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>>>>
>>>>>>
>>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>>>>
>>>>>> Out of nearly 3000 packages, he found 22 were broken by
>>>>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Adam Gundry, Haskell Consultant
>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>>
>>>>>> Registered in England & Wales, OC335890
>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230919/7f4b6078/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Sep 19 19:59:41 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 19 Sep 2023 20:59:41 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAGwnsnmWDwh88CbFYTtZaZ=Sn-yC+MYYQT4WbAXMR0u4vxrw2Q@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <CANsrgPKvA2G2Gy+58WehFUvnNwVgbK2Y7qKS5XeSZrUymrWwvw@mail.gmail.com>
 <CABSB5jVKEGSxJxM0Dh78VM+A9r8X1x45pZ_p8LSC+VpV_gUMPw@mail.gmail.com>
 <CAGwnsnmWDwh88CbFYTtZaZ=Sn-yC+MYYQT4WbAXMR0u4vxrw2Q@mail.gmail.com>
Message-ID: <CAJKmMz9=-DdfiVvkb4m=Ay=hb0N+A7+c+U7Dc2mQeFhvTCt6FQ@mail.gmail.com>

See discussion on the CLC issue
https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889

Some are positively keen on making severe warnings into errors by default,
just the opposite of our current discussion!

Simon

On Tue, 19 Sept 2023 at 17:21, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Is the general consensus on this thread that defaults should never change,
> even if better defaults are discovered?
>
> On Tue, 19 Sept 2023 at 17:13, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> My opposition is entirely grounded in the change of default behaviour;
>> otherwise i am in favour.
>>
>> On Tue, 19 Sep 2023 at 15:31, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> On Tue, 19 Sept 2023 at 15:26, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> I think that the motivation for this proposal is to make it harder to
>>>> shoot yourself in the foot.
>>>>
>>>> Maybe implementing this "severe" *category*, but not changing its *default
>>>> *to error, would get us some of the way there?  Then "best-practice
>>>> guidance" could be "use -Werror=severe", and job done.  That's a bit easier
>>>> to say than saying "use -Werrror=missing-methods -Werror= ..." etc.
>>>>
>>>
>>> Absolutely! I'm only objecting to changing the default. Adding the
>>> "severe" category by itself is useful, I agree.
>>>
>>> Cheers
>>> Simon
>>>
>>>
>>>>
>>>> Simon
>>>>
>>>> On Tue, 19 Sept 2023 at 14:35, Chris Dornan <chris at chrisdornan.com>
>>>> wrote:
>>>>
>>>>> Like Simon M I habitually develop with -Wall -Werror, and like Moritz
>>>>> I think we really need to be very careful about deliberately breaking
>>>>> packages.
>>>>>
>>>>> For sure, if we were starting anew I would be be sympathetic to
>>>>> treating them as errors, but, for me, that isn't a good enough reason to
>>>>> make this breaking change.
>>>>>
>>>>> For this reason I vote against this proposal.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 19 Sep 2023, at 14:20, Simon Marlow <marlowsd at gmail.com> wrote:
>>>>>
>>>>> For those not aware, Hackage right now rejects packages with `-Wall
>>>>> -Werror` in their ghc-options because warnings change between GHC versions
>>>>> so this tends to lead to unnecessary breakage. I think that's a good
>>>>> policy, even though I use `-Wall -Werror` everywhere when developing.
>>>>>
>>>>> Interestingly, this proposal creates exactly the same kind of risk, by
>>>>> making some existing warnings errors by default and introducing the
>>>>> possibility that the set of warnings treated this way might change in the
>>>>> future. Admittedly it's a smaller risk than `-Wall -Werror`, but it's still
>>>>> a risk for developers.
>>>>>
>>>>> Also note that `ghc -XHaskell2010` will reject some legal Haskell2010
>>>>> programs, unless you also say `-Wwarn=severe`. We are normally careful to
>>>>> document the ways in which GHC deviates from the language definition in the
>>>>> user guide.
>>>>>
>>>>> I can see the motivation, but I have to vote against here. I don't
>>>>> think we should change the set of programs accepted by the compiler unless
>>>>> absolutely necessary. If it's legal code today, it should be accepted by
>>>>> future versions of the compiler unless we have a really good reason to
>>>>> change that.
>>>>>
>>>>> Cheers
>>>>> Simon
>>>>>
>>>>>
>>>>> On Tue, 19 Sept 2023 at 08:53, Moritz Angermann <
>>>>> moritz.angermann at gmail.com> wrote:
>>>>>
>>>>>> Just to clarify: I am not against change, or evolution.  I'm actually
>>>>>> looking forward to progress. What I am against ist sudden breakage.
>>>>>> As such, if there _is_ breakage (clc stackage is a subset), we have
>>>>>> to assume there will be breakage in production codebases, most
>>>>>> of which are likely not public.
>>>>>>
>>>>>> Can't we have `-Wcompat` enable `-Werror=missing-methods`, and
>>>>>> `-Werror=missing-fields` (I guess that's the same as `-Werror=sever`?)
>>>>>> Advertise this prominently in the release notes for GHC 9.10? And
>>>>>> then enable this fully in GHC 9.14? Though I guess the flag we want
>>>>>> is really `-Wcompat-error`, or we rather change the notion of
>>>>>> -Wcompat to also promote warnings to errors early? In any case either the
>>>>>> current documentation for -Wcompat would need to be adjusted, or we'd
>>>>>> need something that signals new errors.
>>>>>>
>>>>>> Ideally I'd like to see something like a warning for
>>>>>> `missing-methods`, with an additional note that this will become an error
>>>>>> in GHC X.Y,
>>>>>> and that one can opt into this behaviour by enabling -Wcompat.
>>>>>>
>>>>>> My test for support is generally: can I take existing code
>>>>>> unmodified, swap out the compiler, and it will still compile? That way I
>>>>>> can report
>>>>>> back regressions, bugs, ... early on during alphas, betas, and
>>>>>> release candidates. Right now I can't. I usually have to wait for x.y.4+.
>>>>>> That
>>>>>> also means the feedback for anyone working on GHC is terrible. You
>>>>>> won't hear about bugs until late in the release cycle where the
>>>>>> master branch has moved forward by a lot. At the same time it's
>>>>>> painful for integrators who end up having to backport and patch old
>>>>>> branches. https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status
>>>>>> already states anything but 9.4 and 9.6 won't see any further releases.
>>>>>> Our current production compiler is 8.10, we could not switch to 9.2
>>>>>> due to performance regressions. And finally have almost everything
>>>>>> compiling with 9.6, but are far from having any form of performance
>>>>>> profile feedback on 9.6 yet.
>>>>>>
>>>>>> Again, I'm not against breakage per-se. I'm against sudden breakage.
>>>>>> Managed evolution or however we want to call it, is something
>>>>>> I'd absolutely support!
>>>>>>
>>>>>> Best,
>>>>>>  Moritz
>>>>>>
>>>>>> On Tue, 19 Sept 2023 at 15:15, Adam Gundry <adam at well-typed.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 18/09/2023 20:28, Richard Eisenberg wrote:
>>>>>>> >
>>>>>>> > Bottom line for me: I think we should implement and then
>>>>>>> experiment.
>>>>>>> > Given the potentially delicate nature of this, I might even
>>>>>>> advocate for
>>>>>>> > implementing this in a release branch, so that as much of Hackage
>>>>>>> as
>>>>>>> > possible actually has a hope of compiling. Then test to see where
>>>>>>> the
>>>>>>> > breakage occurs. If were happy with the result, rebase the
>>>>>>> > implementation on master. But I don't want us to get into a state
>>>>>>> where
>>>>>>> > we accept, implement, observe moderate breakage, and then blast
>>>>>>> ahead
>>>>>>> > because the committee approved the idea.
>>>>>>>
>>>>>>> The breakage concern is worth thinking about, I agree, but
>>>>>>> fortunately
>>>>>>> in this instance we don't need to wait for an implementation to run
>>>>>>> an
>>>>>>> experiment. The change can be relatively effectively simulated by
>>>>>>> compiling with -Werror=missing-methods -Werror=missing-fields, and
>>>>>>> indeed Oleg has done so already for clc-stackage as he reports here:
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issue-1410125536
>>>>>>>
>>>>>>>
>>>>>>> https://github.com/ghc-proposals/ghc-proposals/issues/544#issuecomment-1279948737
>>>>>>>
>>>>>>> Out of nearly 3000 packages, he found 22 were broken by
>>>>>>> -Werror=missing-methods and 9 by -Werror=missing-fields.
>>>>>>>
>>>>>>> Adam
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Adam Gundry, Haskell Consultant
>>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>>>
>>>>>>> Registered in England & Wales, OC335890
>>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20230919/30c7e476/attachment.html>

From mail at joachim-breitner.de  Tue Sep 19 21:13:20 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 19 Sep 2023 23:13:20 +0200
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
Message-ID: <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
> Maybe implementing this "severe" category, but not changing its
> default to error, would get us some of the way there?  Then "best-
> practice guidance" could be "use -Werror=severe", and job done. 
> That's a bit easier to say than saying "use -Werrror=missing-methods
> -Werror= ..." etc.

anyone using `-Werror` would already get this behavior. So what is the
useful for using `-Werror=severe` instead? Presumably the rationale is:

 -Werror, while great _during_ development or in leaf packages, is not
 is not good idea in _released_ code, i.e. code that is compiled by 
 others, as that code needs to keep working even as compilers and
 dependencies change, such as libraries on hackage, or executables
 built by distro packagers.
 That’s why -Werror is frowned upon there.

 But some changes in upstream packages _ought_ to cause compilation to
 fail, because they really need downstream code changes. These will
 cause severe warnings, and therefore -Werror=severe is desirable
 even for released code.

Is that a good way of phrasing your thoughts there?

It looks reasonable to me; if we think of deferable type error as
severe warnings, it totally fits this description: It would be
_possible_ to keep compiling the downstream code, but it would not be
desirable. That's why compilation fails, and that’s why we don’t defer
type errors by default.

But if -Werror=severe is desirable generally, it would be unfortunate
if we cannot make it the default. If not right away, then maybe with a
suitable migration strategy? (Although I wonder if there are many users
out there that pay attention to deprecation warnings, e.g. watch
-Wdeprecation, that would not have already fixed -Wdefault warnings
about missing fields/methods already…)


Cheers,
Joachim



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


From adam at well-typed.com  Wed Sep 20 07:25:21 2023
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 20 Sep 2023 08:25:21 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
Message-ID: <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>

I agree with Joachim's position here.

Having a -Wsevere group at all would be a good start, but the problem 
with stopping at "best-practice guidance" rather than changing the 
defaults is that it benefits only those who learn about and follow the 
guidance. So it remains a footgun for newcomers.

Regarding migration, given that GHC has issued these warnings by default 
for some time, I don't think we need be too shy about upgrading their 
severity. We could have -Wcompat imply -Werror=severe, but that 
complicates the semantics of warning groups, and will help only those 
who use -Wcompat but don't fix warnings that occur with -Wdefault.

I suppose as Moritz suggests we could introduce and advertise -Wsevere 
in 9.10, and mention in the warning message that this will be an error 
in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 
9.10 would give something like:

M.hs:8:10: warning: [-Wmissing-methods]
     • No explicit implementation for
         ‘<>’
     • In the instance declaration for ‘Semigroup T’
     • Warning: this may lead to an infinite loop or runtime exception.
     • This will become an error by default in a future GHC release;
       use -Werror=severe to make severe warnings into errors now.

Then in a future release:

M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
     • No explicit implementation for
         ‘<>’
     • In the instance declaration for ‘Semigroup T’
     • Warning: this may lead to an infinite loop or runtime exception.
     • Use -Wwarn=missing-methods to permit this anyway.

Would that be a reasonable compromise?

Adam


On 19/09/2023 22:13, Joachim Breitner wrote:
> Hi,
> 
> Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>> Maybe implementing this "severe" category, but not changing its
>> default to error, would get us some of the way there?  Then "best-
>> practice guidance" could be "use -Werror=severe", and job done.
>> That's a bit easier to say than saying "use -Werrror=missing-methods
>> -Werror= ..." etc.
> 
> anyone using `-Werror` would already get this behavior. So what is the
> useful for using `-Werror=severe` instead? Presumably the rationale is:
> 
>   -Werror, while great _during_ development or in leaf packages, is not
>   is not good idea in _released_ code, i.e. code that is compiled by
>   others, as that code needs to keep working even as compilers and
>   dependencies change, such as libraries on hackage, or executables
>   built by distro packagers.
>   That’s why -Werror is frowned upon there.
> 
>   But some changes in upstream packages _ought_ to cause compilation to
>   fail, because they really need downstream code changes. These will
>   cause severe warnings, and therefore -Werror=severe is desirable
>   even for released code.
> 
> Is that a good way of phrasing your thoughts there?
> 
> It looks reasonable to me; if we think of deferable type error as
> severe warnings, it totally fits this description: It would be
> _possible_ to keep compiling the downstream code, but it would not be
> desirable. That's why compilation fails, and that’s why we don’t defer
> type errors by default.
> 
> But if -Werror=severe is desirable generally, it would be unfortunate
> if we cannot make it the default. If not right away, then maybe with a
> suitable migration strategy? (Although I wonder if there are many users
> out there that pay attention to deprecation warnings, e.g. watch
> -Wdeprecation, that would not have already fixed -Wdefault warnings
> about missing fields/methods already…)
> 
> 
> Cheers,
> Joachim

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From moritz.angermann at gmail.com  Wed Sep 20 07:30:18 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 20 Sep 2023 15:30:18 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
Message-ID: <CAKfdd-wSndefRravB9JYADbX3YF63bYtNSitEAa8PGsQYZbAeQ@mail.gmail.com>

Adam,

yes. That would be great and resolve my reservations!

Cheers,
 Moritz

On Wed, 20 Sept 2023 at 15:25, Adam Gundry <adam at well-typed.com> wrote:

> I agree with Joachim's position here.
>
> Having a -Wsevere group at all would be a good start, but the problem
> with stopping at "best-practice guidance" rather than changing the
> defaults is that it benefits only those who learn about and follow the
> guidance. So it remains a footgun for newcomers.
>
> Regarding migration, given that GHC has issued these warnings by default
> for some time, I don't think we need be too shy about upgrading their
> severity. We could have -Wcompat imply -Werror=severe, but that
> complicates the semantics of warning groups, and will help only those
> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>
> I suppose as Moritz suggests we could introduce and advertise -Wsevere
> in 9.10, and mention in the warning message that this will be an error
> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
> 9.10 would give something like:
>
> M.hs:8:10: warning: [-Wmissing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • This will become an error by default in a future GHC release;
>        use -Werror=severe to make severe warnings into errors now.
>
> Then in a future release:
>
> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • Use -Wwarn=missing-methods to permit this anyway.
>
> Would that be a reasonable compromise?
>
> Adam
>
>
> On 19/09/2023 22:13, Joachim Breitner wrote:
> > Hi,
> >
> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
> >> Maybe implementing this "severe" category, but not changing its
> >> default to error, would get us some of the way there?  Then "best-
> >> practice guidance" could be "use -Werror=severe", and job done.
> >> That's a bit easier to say than saying "use -Werrror=missing-methods
> >> -Werror= ..." etc.
> >
> > anyone using `-Werror` would already get this behavior. So what is the
> > useful for using `-Werror=severe` instead? Presumably the rationale is:
> >
> >   -Werror, while great _during_ development or in leaf packages, is not
> >   is not good idea in _released_ code, i.e. code that is compiled by
> >   others, as that code needs to keep working even as compilers and
> >   dependencies change, such as libraries on hackage, or executables
> >   built by distro packagers.
> >   That’s why -Werror is frowned upon there.
> >
> >   But some changes in upstream packages _ought_ to cause compilation to
> >   fail, because they really need downstream code changes. These will
> >   cause severe warnings, and therefore -Werror=severe is desirable
> >   even for released code.
> >
> > Is that a good way of phrasing your thoughts there?
> >
> > It looks reasonable to me; if we think of deferable type error as
> > severe warnings, it totally fits this description: It would be
> > _possible_ to keep compiling the downstream code, but it would not be
> > desirable. That's why compilation fails, and that’s why we don’t defer
> > type errors by default.
> >
> > But if -Werror=severe is desirable generally, it would be unfortunate
> > if we cannot make it the default. If not right away, then maybe with a
> > suitable migration strategy? (Although I wonder if there are many users
> > out there that pay attention to deprecation warnings, e.g. watch
> > -Wdeprecation, that would not have already fixed -Wdefault warnings
> > about missing fields/methods already…)
> >
> >
> > Cheers,
> > Joachim
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230920/75b16b1c/attachment.html>

From simon.peytonjones at gmail.com  Wed Sep 20 09:12:00 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 20 Sep 2023 10:12:00 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-wSndefRravB9JYADbX3YF63bYtNSitEAa8PGsQYZbAeQ@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CAKfdd-wSndefRravB9JYADbX3YF63bYtNSitEAa8PGsQYZbAeQ@mail.gmail.com>
Message-ID: <CAJKmMz98jxxdNnkbeo5GPi3pq_0rBknrg05h=Q-Vsje5yirm-w@mail.gmail.com>

>
> yes. That would be great and resolve my reservations!
>

Great.  I think the CLC would actively support this too, if I read their
comments correctly.

Simon

On Wed, 20 Sept 2023 at 08:30, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Adam,
>
> yes. That would be great and resolve my reservations!
>
> Cheers,
>  Moritz
>
> On Wed, 20 Sept 2023 at 15:25, Adam Gundry <adam at well-typed.com> wrote:
>
>> I agree with Joachim's position here.
>>
>> Having a -Wsevere group at all would be a good start, but the problem
>> with stopping at "best-practice guidance" rather than changing the
>> defaults is that it benefits only those who learn about and follow the
>> guidance. So it remains a footgun for newcomers.
>>
>> Regarding migration, given that GHC has issued these warnings by default
>> for some time, I don't think we need be too shy about upgrading their
>> severity. We could have -Wcompat imply -Werror=severe, but that
>> complicates the semantics of warning groups, and will help only those
>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>
>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>> in 9.10, and mention in the warning message that this will be an error
>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>> 9.10 would give something like:
>>
>> M.hs:8:10: warning: [-Wmissing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • This will become an error by default in a future GHC release;
>>        use -Werror=severe to make severe warnings into errors now.
>>
>> Then in a future release:
>>
>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • Use -Wwarn=missing-methods to permit this anyway.
>>
>> Would that be a reasonable compromise?
>>
>> Adam
>>
>>
>> On 19/09/2023 22:13, Joachim Breitner wrote:
>> > Hi,
>> >
>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>> >> Maybe implementing this "severe" category, but not changing its
>> >> default to error, would get us some of the way there?  Then "best-
>> >> practice guidance" could be "use -Werror=severe", and job done.
>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>> >> -Werror= ..." etc.
>> >
>> > anyone using `-Werror` would already get this behavior. So what is the
>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>> >
>> >   -Werror, while great _during_ development or in leaf packages, is not
>> >   is not good idea in _released_ code, i.e. code that is compiled by
>> >   others, as that code needs to keep working even as compilers and
>> >   dependencies change, such as libraries on hackage, or executables
>> >   built by distro packagers.
>> >   That’s why -Werror is frowned upon there.
>> >
>> >   But some changes in upstream packages _ought_ to cause compilation to
>> >   fail, because they really need downstream code changes. These will
>> >   cause severe warnings, and therefore -Werror=severe is desirable
>> >   even for released code.
>> >
>> > Is that a good way of phrasing your thoughts there?
>> >
>> > It looks reasonable to me; if we think of deferable type error as
>> > severe warnings, it totally fits this description: It would be
>> > _possible_ to keep compiling the downstream code, but it would not be
>> > desirable. That's why compilation fails, and that’s why we don’t defer
>> > type errors by default.
>> >
>> > But if -Werror=severe is desirable generally, it would be unfortunate
>> > if we cannot make it the default. If not right away, then maybe with a
>> > suitable migration strategy? (Although I wonder if there are many users
>> > out there that pay attention to deprecation warnings, e.g. watch
>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>> > about missing fields/methods already…)
>> >
>> >
>> > Cheers,
>> > Joachim
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230920/cc2bb98a/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Sep 21 07:37:09 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 21 Sep 2023 09:37:09 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
Message-ID: <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>

Dear all.

I submitted my recommendation 3 weeks ago, and only Simon has commented
yet. Please let me know your thoughts.

On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Don't forget to opine here. To reiterate, I really don't expect the
> proposal to be controversial. The text of the proposal is rather long, but
> is made easy to read. So it shouldn't take too much of your time.
>
> /Arnaud
>
> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> I support acceptance.
>>
>> Simon
>>
>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583
>>> ]
>>>
>>> Our own Adam proposes to amend the design of the highly experimental
>>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>>>
>>> Specifically, Adam proposes a modification of the type classes that
>>> would back the extension.
>>>
>>> In the previous design the HasField class is defined as a lens:
>>>
>>> class HasField (n :: k) r a | r n -> a
>>>   hasField :: r -> (a -> r, a)
>>>
>>> The proposal is to replace it by two classes (slightly simplified)
>>>
>>> class HasField (n :: k) r a | r n -> a
>>>   hasField :: r -> a
>>>
>>> class SetField (n::k) r a | r n -> a
>>>   modifyField :: (a -> a) -> r -> a
>>>   setField :: a -> r -> a
>>>
>>> This is originally motivated by some performance consideration: the
>>> prototype implementation of HasField as a lens can be very time consuming
>>> because instances of HasFields are generated eagerly at record definition
>>> sites, whereas the simple HasField instances can simply reuse the selectors
>>> already generated by GHC. But a lot of thoughts have been put into the new
>>> design, and my summary can certainly not do it justice: the proposal is
>>> very well argumented.
>>>
>>> A point I'll make here is that the new design is actually parametric in
>>> the data representation of the field type. Something that wasn't possible
>>> in the original design.
>>>
>>> This proposal is not technically backward compatible, because the order
>>> of argument in which OverloadedRecordUpdate expects the argument of
>>> setField is changed. This is not essential to the proposal, but this is a
>>> more consistent order argument with the rest of Haskell. And considering
>>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>>> recommend accepting this breakage.
>>>
>>> Overall the proposal is actually more backward compatible with GHC 9.8
>>> than the original design, as the HasField class is left unchanged.
>>>
>>> Overall, the proposal looks quite reasonable to me, and well-argued. I
>>> recommend acceptance.
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230921/721d4533/attachment.html>

From chris at chrisdornan.com  Thu Sep 21 08:35:28 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 21 Sep 2023 09:35:28 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
Message-ID: <CABSB5jWeekoKYeKnAXQJLn5FPp6Knd2Y=dBACrPuhx-mprZG8w@mail.gmail.com>

+1 from me

On Thu, 21 Sep 2023 at 08:37, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all.
>
> I submitted my recommendation 3 weeks ago, and only Simon has commented
> yet. Please let me know your thoughts.
>
> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> Don't forget to opine here. To reiterate, I really don't expect the
>> proposal to be controversial. The text of the proposal is rather long, but
>> is made easy to read. So it shouldn't take too much of your time.
>>
>> /Arnaud
>>
>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> I support acceptance.
>>>
>>> Simon
>>>
>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583
>>>> ]
>>>>
>>>> Our own Adam proposes to amend the design of the highly experimental
>>>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>>>>
>>>> Specifically, Adam proposes a modification of the type classes that
>>>> would back the extension.
>>>>
>>>> In the previous design the HasField class is defined as a lens:
>>>>
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> (a -> r, a)
>>>>
>>>> The proposal is to replace it by two classes (slightly simplified)
>>>>
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> a
>>>>
>>>> class SetField (n::k) r a | r n -> a
>>>>   modifyField :: (a -> a) -> r -> a
>>>>   setField :: a -> r -> a
>>>>
>>>> This is originally motivated by some performance consideration: the
>>>> prototype implementation of HasField as a lens can be very time consuming
>>>> because instances of HasFields are generated eagerly at record definition
>>>> sites, whereas the simple HasField instances can simply reuse the selectors
>>>> already generated by GHC. But a lot of thoughts have been put into the new
>>>> design, and my summary can certainly not do it justice: the proposal is
>>>> very well argumented.
>>>>
>>>> A point I'll make here is that the new design is actually parametric in
>>>> the data representation of the field type. Something that wasn't possible
>>>> in the original design.
>>>>
>>>> This proposal is not technically backward compatible, because the order
>>>> of argument in which OverloadedRecordUpdate expects the argument of
>>>> setField is changed. This is not essential to the proposal, but this is a
>>>> more consistent order argument with the rest of Haskell. And considering
>>>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>>>> recommend accepting this breakage.
>>>>
>>>> Overall the proposal is actually more backward compatible with GHC 9.8
>>>> than the original design, as the HasField class is left unchanged.
>>>>
>>>> Overall, the proposal looks quite reasonable to me, and well-argued. I
>>>> recommend acceptance.
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>>
>
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20230921/c59b1a25/attachment.html>

From vlad.z.4096 at gmail.com  Thu Sep 21 09:12:32 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Thu, 21 Sep 2023 11:12:32 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CABSB5jWeekoKYeKnAXQJLn5FPp6Knd2Y=dBACrPuhx-mprZG8w@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <CABSB5jWeekoKYeKnAXQJLn5FPp6Knd2Y=dBACrPuhx-mprZG8w@mail.gmail.com>
Message-ID: <CAHZ0NLrhySpMKkoDaLfCsL+P9H0tqu_e9B-Z8jUgOYDYABRZPQ@mail.gmail.com>

I'm against the proposal in its current form because it does not support
type-changing update and is not forward-compatible with it. Fortunately, it
is not hard to fix this, as Adam points out in a GitHub comment:

> I suppose one thing we could do now would be to add the parameters for
type-changing update already, but restrict the constraint solver behaviour,
e.g. define the classes SetField x s t a b and type SetField' x r a =
SetField x r r a a, but have the constraint solver always unify s ~ t and a
~ b when solving constraints. That would limit (but not necessarily
eliminate) the breakage when generalising the constraint solver.

Let's do it this way to avoid a breaking change in the future!

Vlad

On Thu, Sep 21, 2023 at 10:35 AM Chris Dornan <chris at chrisdornan.com> wrote:

> +1 from me
>
> On Thu, 21 Sep 2023 at 08:37, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all.
>>
>> I submitted my recommendation 3 weeks ago, and only Simon has commented
>> yet. Please let me know your thoughts.
>>
>> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> Don't forget to opine here. To reiterate, I really don't expect the
>>> proposal to be controversial. The text of the proposal is rather long, but
>>> is made easy to read. So it shouldn't take too much of your time.
>>>
>>> /Arnaud
>>>
>>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> I support acceptance.
>>>>
>>>> Simon
>>>>
>>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>> wrote:
>>>>
>>>>> Dear all,
>>>>>
>>>>> [ Proposal #583
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>>>>>
>>>>> Our own Adam proposes to amend the design of the highly experimental
>>>>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405
>>>>> ].
>>>>>
>>>>> Specifically, Adam proposes a modification of the type classes that
>>>>> would back the extension.
>>>>>
>>>>> In the previous design the HasField class is defined as a lens:
>>>>>
>>>>> class HasField (n :: k) r a | r n -> a
>>>>>   hasField :: r -> (a -> r, a)
>>>>>
>>>>> The proposal is to replace it by two classes (slightly simplified)
>>>>>
>>>>> class HasField (n :: k) r a | r n -> a
>>>>>   hasField :: r -> a
>>>>>
>>>>> class SetField (n::k) r a | r n -> a
>>>>>   modifyField :: (a -> a) -> r -> a
>>>>>   setField :: a -> r -> a
>>>>>
>>>>> This is originally motivated by some performance consideration: the
>>>>> prototype implementation of HasField as a lens can be very time consuming
>>>>> because instances of HasFields are generated eagerly at record definition
>>>>> sites, whereas the simple HasField instances can simply reuse the selectors
>>>>> already generated by GHC. But a lot of thoughts have been put into the new
>>>>> design, and my summary can certainly not do it justice: the proposal is
>>>>> very well argumented.
>>>>>
>>>>> A point I'll make here is that the new design is actually parametric
>>>>> in the data representation of the field type. Something that wasn't
>>>>> possible in the original design.
>>>>>
>>>>> This proposal is not technically backward compatible, because the
>>>>> order of argument in which OverloadedRecordUpdate expects the argument of
>>>>> setField is changed. This is not essential to the proposal, but this is a
>>>>> more consistent order argument with the rest of Haskell. And considering
>>>>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>>>>> recommend accepting this breakage.
>>>>>
>>>>> Overall the proposal is actually more backward compatible with GHC 9.8
>>>>> than the original design, as the HasField class is left unchanged.
>>>>>
>>>>> Overall, the proposal looks quite reasonable to me, and well-argued. I
>>>>> recommend acceptance.
>>>>>
>>>>> --
>>>>> Arnaud Spiwack
>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>> _______________________________________________
>>>>> ghc-steering-committee mailing list
>>>>> ghc-steering-committee at haskell.org
>>>>>
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>
>>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> 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/20230921/aa47514d/attachment-0001.html>

From marlowsd at gmail.com  Thu Sep 21 12:34:44 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 21 Sep 2023 13:34:44 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
Message-ID: <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>

I might be an outlier here, but deferring the change to a later release and
adding an intermediate warning doesn't make it any less bad.

This is one cultural aspect of our community I'd like to shift: the
expectation that it's OK to make breaking changes as long as you warn about
them or go through a migration cycle. It just isn't! (and I speak as
someone who used to make lots of changes, I'm now fully repentant!). That's
not to say that we shouldn't ever change anything, but when considering the
cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
just defers it.

Cheers
Simon



On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:

> I agree with Joachim's position here.
>
> Having a -Wsevere group at all would be a good start, but the problem
> with stopping at "best-practice guidance" rather than changing the
> defaults is that it benefits only those who learn about and follow the
> guidance. So it remains a footgun for newcomers.
>
> Regarding migration, given that GHC has issued these warnings by default
> for some time, I don't think we need be too shy about upgrading their
> severity. We could have -Wcompat imply -Werror=severe, but that
> complicates the semantics of warning groups, and will help only those
> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>
> I suppose as Moritz suggests we could introduce and advertise -Wsevere
> in 9.10, and mention in the warning message that this will be an error
> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
> 9.10 would give something like:
>
> M.hs:8:10: warning: [-Wmissing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • This will become an error by default in a future GHC release;
>        use -Werror=severe to make severe warnings into errors now.
>
> Then in a future release:
>
> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • Use -Wwarn=missing-methods to permit this anyway.
>
> Would that be a reasonable compromise?
>
> Adam
>
>
> On 19/09/2023 22:13, Joachim Breitner wrote:
> > Hi,
> >
> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
> >> Maybe implementing this "severe" category, but not changing its
> >> default to error, would get us some of the way there?  Then "best-
> >> practice guidance" could be "use -Werror=severe", and job done.
> >> That's a bit easier to say than saying "use -Werrror=missing-methods
> >> -Werror= ..." etc.
> >
> > anyone using `-Werror` would already get this behavior. So what is the
> > useful for using `-Werror=severe` instead? Presumably the rationale is:
> >
> >   -Werror, while great _during_ development or in leaf packages, is not
> >   is not good idea in _released_ code, i.e. code that is compiled by
> >   others, as that code needs to keep working even as compilers and
> >   dependencies change, such as libraries on hackage, or executables
> >   built by distro packagers.
> >   That’s why -Werror is frowned upon there.
> >
> >   But some changes in upstream packages _ought_ to cause compilation to
> >   fail, because they really need downstream code changes. These will
> >   cause severe warnings, and therefore -Werror=severe is desirable
> >   even for released code.
> >
> > Is that a good way of phrasing your thoughts there?
> >
> > It looks reasonable to me; if we think of deferable type error as
> > severe warnings, it totally fits this description: It would be
> > _possible_ to keep compiling the downstream code, but it would not be
> > desirable. That's why compilation fails, and that’s why we don’t defer
> > type errors by default.
> >
> > But if -Werror=severe is desirable generally, it would be unfortunate
> > if we cannot make it the default. If not right away, then maybe with a
> > suitable migration strategy? (Although I wonder if there are many users
> > out there that pay attention to deprecation warnings, e.g. watch
> > -Wdeprecation, that would not have already fixed -Wdefault warnings
> > about missing fields/methods already…)
> >
> >
> > Cheers,
> > Joachim
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230921/dd3de18e/attachment.html>

From lists at richarde.dev  Thu Sep 21 12:51:56 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 21 Sep 2023 12:51:56 +0000
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
Message-ID: <010f018ab7cc081c-164e37b3-30a6-44bf-a477-9ec010271d04-000000@us-east-2.amazonses.com>

I will mull on the actual proposal (I feel there is a solution somewhere here that we haven't hit yet), but I wanted to respond to Simon M's comment about deferred cost: The migration cycle is more than just a deferment: it's a smearing. That is, if something breaks suddenly, everyone must upgrade in unison: hard. If something breaks slowly, then people can update their projects when they choose during the migration period: much easier. That difference might not affect an enterprise all that much, but I think it has a sizable impact on open-source developers.

Richard

> On Sep 21, 2023, at 8:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.
> 
> This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.
> 
> Cheers
> Simon
> 
> 
> 
> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> I agree with Joachim's position here.
> 
> Having a -Wsevere group at all would be a good start, but the problem 
> with stopping at "best-practice guidance" rather than changing the 
> defaults is that it benefits only those who learn about and follow the 
> guidance. So it remains a footgun for newcomers.
> 
> Regarding migration, given that GHC has issued these warnings by default 
> for some time, I don't think we need be too shy about upgrading their 
> severity. We could have -Wcompat imply -Werror=severe, but that 
> complicates the semantics of warning groups, and will help only those 
> who use -Wcompat but don't fix warnings that occur with -Wdefault.
> 
> I suppose as Moritz suggests we could introduce and advertise -Wsevere 
> in 9.10, and mention in the warning message that this will be an error 
> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 
> 9.10 would give something like:
> 
> M.hs:8:10: warning: [-Wmissing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • This will become an error by default in a future GHC release;
>        use -Werror=severe to make severe warnings into errors now.
> 
> Then in a future release:
> 
> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>      • No explicit implementation for
>          ‘<>’
>      • In the instance declaration for ‘Semigroup T’
>      • Warning: this may lead to an infinite loop or runtime exception.
>      • Use -Wwarn=missing-methods to permit this anyway.
> 
> Would that be a reasonable compromise?
> 
> Adam
> 
> 
> On 19/09/2023 22:13, Joachim Breitner wrote:
> > Hi,
> > 
> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
> >> Maybe implementing this "severe" category, but not changing its
> >> default to error, would get us some of the way there?  Then "best-
> >> practice guidance" could be "use -Werror=severe", and job done.
> >> That's a bit easier to say than saying "use -Werrror=missing-methods
> >> -Werror= ..." etc.
> > 
> > anyone using `-Werror` would already get this behavior. So what is the
> > useful for using `-Werror=severe` instead? Presumably the rationale is:
> > 
> >   -Werror, while great _during_ development or in leaf packages, is not
> >   is not good idea in _released_ code, i.e. code that is compiled by
> >   others, as that code needs to keep working even as compilers and
> >   dependencies change, such as libraries on hackage, or executables
> >   built by distro packagers.
> >   That’s why -Werror is frowned upon there.
> > 
> >   But some changes in upstream packages _ought_ to cause compilation to
> >   fail, because they really need downstream code changes. These will
> >   cause severe warnings, and therefore -Werror=severe is desirable
> >   even for released code.
> > 
> > Is that a good way of phrasing your thoughts there?
> > 
> > It looks reasonable to me; if we think of deferable type error as
> > severe warnings, it totally fits this description: It would be
> > _possible_ to keep compiling the downstream code, but it would not be
> > desirable. That's why compilation fails, and that’s why we don’t defer
> > type errors by default.
> > 
> > But if -Werror=severe is desirable generally, it would be unfortunate
> > if we cannot make it the default. If not right away, then maybe with a
> > suitable migration strategy? (Although I wonder if there are many users
> > out there that pay attention to deprecation warnings, e.g. watch
> > -Wdeprecation, that would not have already fixed -Wdefault warnings
> > about missing fields/methods already…)
> > 
> > 
> > Cheers,
> > Joachim
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
> 
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> 
> _______________________________________________
> 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/20230921/e7b8eba4/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Sep 21 13:13:32 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 21 Sep 2023 21:13:32 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
Message-ID: <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>

Thank you Simon!

I think this raises a good point, in that _any_ breaking change should
stand well on its own wrt to a cost/benefit analysis.

I’m not sure if we disagree or not.  I’ve assumed that the majority wants
to make these changes.  I also often do not feel sufficiently capable
enough to make a convincing argument against a specific change.

Thus under the assumption that we are going to make a breaking change
(because the majority want this), I feel very strongly about informing end
users beforehand as well as the quality control aspect of being able to run
regression tests by just swapping out the compiler trivially.

Thus *if* we are making a breaking change, I do not believe that a
migration phase reduces the costs much (you still need to adjust your
code), but I consider a breaking change without migration phase to be
significantly worse to a breaking change with migration phase.

The difference for me practically lies in the following:
If we migrate to a new compiler, a team of engineers start doing the
initial migration for us (this means adding the new compiler to CI, and
making sure existing code at least builds), this happens for multiple
projects/components in dependency order.

After this has happened the project/component teams use the new compiler
and fix their code.

If we have migration warnings for upcoming breaking changes, the work
shifts from the new-compiler-across-multiple-projects team into the project
teams.

This makes the whole add new compiler process significantly faster, and
means less friction. It also means the project teams who have much better
knowledge of their specific project can address the warnings better than
the migration team which has to dig deep into existing code bases, get
familiar with the code to make the necessity adjustments (or request pair
sessions that take time from other tasks).

It also gives one more opportunity for the community to raise their hand
and say, oh hell no, that’s a stupid idea; I’m going to complain about
this! (I’ve been told this more than once; migration phases could also be
seen as community inquiery, to get feedback from actual practitioners).

After writing this all down, I guess my push for “if breaking change, then
only with migration phase” is orthogonal to “should we have breaking
changes to begin with?”

Cheers,
  Moritz

On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow <marlowsd at gmail.com> wrote:

> I might be an outlier here, but deferring the change to a later release
> and adding an intermediate warning doesn't make it any less bad.
>
> This is one cultural aspect of our community I'd like to shift: the
> expectation that it's OK to make breaking changes as long as you warn about
> them or go through a migration cycle. It just isn't! (and I speak as
> someone who used to make lots of changes, I'm now fully repentant!). That's
> not to say that we shouldn't ever change anything, but when considering the
> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
> just defers it.
>
> Cheers
> Simon
>
>
>
> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>
>> I agree with Joachim's position here.
>>
>> Having a -Wsevere group at all would be a good start, but the problem
>> with stopping at "best-practice guidance" rather than changing the
>> defaults is that it benefits only those who learn about and follow the
>> guidance. So it remains a footgun for newcomers.
>>
>> Regarding migration, given that GHC has issued these warnings by default
>> for some time, I don't think we need be too shy about upgrading their
>> severity. We could have -Wcompat imply -Werror=severe, but that
>> complicates the semantics of warning groups, and will help only those
>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>
>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>> in 9.10, and mention in the warning message that this will be an error
>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>> 9.10 would give something like:
>>
>> M.hs:8:10: warning: [-Wmissing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • This will become an error by default in a future GHC release;
>>        use -Werror=severe to make severe warnings into errors now.
>>
>> Then in a future release:
>>
>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • Use -Wwarn=missing-methods to permit this anyway.
>>
>> Would that be a reasonable compromise?
>>
>> Adam
>>
>>
>> On 19/09/2023 22:13, Joachim Breitner wrote:
>> > Hi,
>> >
>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>> >> Maybe implementing this "severe" category, but not changing its
>> >> default to error, would get us some of the way there?  Then "best-
>> >> practice guidance" could be "use -Werror=severe", and job done.
>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>> >> -Werror= ..." etc.
>> >
>> > anyone using `-Werror` would already get this behavior. So what is the
>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>> >
>> >   -Werror, while great _during_ development or in leaf packages, is not
>> >   is not good idea in _released_ code, i.e. code that is compiled by
>> >   others, as that code needs to keep working even as compilers and
>> >   dependencies change, such as libraries on hackage, or executables
>> >   built by distro packagers.
>> >   That’s why -Werror is frowned upon there.
>> >
>> >   But some changes in upstream packages _ought_ to cause compilation to
>> >   fail, because they really need downstream code changes. These will
>> >   cause severe warnings, and therefore -Werror=severe is desirable
>> >   even for released code.
>> >
>> > Is that a good way of phrasing your thoughts there?
>> >
>> > It looks reasonable to me; if we think of deferable type error as
>> > severe warnings, it totally fits this description: It would be
>> > _possible_ to keep compiling the downstream code, but it would not be
>> > desirable. That's why compilation fails, and that’s why we don’t defer
>> > type errors by default.
>> >
>> > But if -Werror=severe is desirable generally, it would be unfortunate
>> > if we cannot make it the default. If not right away, then maybe with a
>> > suitable migration strategy? (Although I wonder if there are many users
>> > out there that pay attention to deprecation warnings, e.g. watch
>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>> > about missing fields/methods already…)
>> >
>> >
>> > Cheers,
>> > Joachim
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230921/27e75fb9/attachment.html>

From simon.peytonjones at gmail.com  Thu Sep 21 13:43:15 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 21 Sep 2023 14:43:15 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
 <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>
Message-ID: <CAJKmMz_L5sBa7TtiKh7PjKS-UYSebw+C79VmUHPi5ujtSGS=HQ@mail.gmail.com>

Dear GHC SC

I'd love to know your views about the proposed "General Rules" described
here:
https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305

If we knew our stance on these, it might help with our debate about the
particular proposal #571.

Thanks

Simon

On Thu, 21 Sept 2023 at 14:13, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Thank you Simon!
>
> I think this raises a good point, in that _any_ breaking change should
> stand well on its own wrt to a cost/benefit analysis.
>
> I’m not sure if we disagree or not.  I’ve assumed that the majority wants
> to make these changes.  I also often do not feel sufficiently capable
> enough to make a convincing argument against a specific change.
>
> Thus under the assumption that we are going to make a breaking change
> (because the majority want this), I feel very strongly about informing end
> users beforehand as well as the quality control aspect of being able to run
> regression tests by just swapping out the compiler trivially.
>
> Thus *if* we are making a breaking change, I do not believe that a
> migration phase reduces the costs much (you still need to adjust your
> code), but I consider a breaking change without migration phase to be
> significantly worse to a breaking change with migration phase.
>
> The difference for me practically lies in the following:
> If we migrate to a new compiler, a team of engineers start doing the
> initial migration for us (this means adding the new compiler to CI, and
> making sure existing code at least builds), this happens for multiple
> projects/components in dependency order.
>
> After this has happened the project/component teams use the new compiler
> and fix their code.
>
> If we have migration warnings for upcoming breaking changes, the work
> shifts from the new-compiler-across-multiple-projects team into the project
> teams.
>
> This makes the whole add new compiler process significantly faster, and
> means less friction. It also means the project teams who have much better
> knowledge of their specific project can address the warnings better than
> the migration team which has to dig deep into existing code bases, get
> familiar with the code to make the necessity adjustments (or request pair
> sessions that take time from other tasks).
>
> It also gives one more opportunity for the community to raise their hand
> and say, oh hell no, that’s a stupid idea; I’m going to complain about
> this! (I’ve been told this more than once; migration phases could also be
> seen as community inquiery, to get feedback from actual practitioners).
>
> After writing this all down, I guess my push for “if breaking change, then
> only with migration phase” is orthogonal to “should we have breaking
> changes to begin with?”
>
> Cheers,
>   Moritz
>
> On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I might be an outlier here, but deferring the change to a later release
>> and adding an intermediate warning doesn't make it any less bad.
>>
>> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!). That's
>> not to say that we shouldn't ever change anything, but when considering the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
>>
>> Cheers
>> Simon
>>
>>
>>
>> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> I agree with Joachim's position here.
>>>
>>> Having a -Wsevere group at all would be a good start, but the problem
>>> with stopping at "best-practice guidance" rather than changing the
>>> defaults is that it benefits only those who learn about and follow the
>>> guidance. So it remains a footgun for newcomers.
>>>
>>> Regarding migration, given that GHC has issued these warnings by default
>>> for some time, I don't think we need be too shy about upgrading their
>>> severity. We could have -Wcompat imply -Werror=severe, but that
>>> complicates the semantics of warning groups, and will help only those
>>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>>
>>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>>> in 9.10, and mention in the warning message that this will be an error
>>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>>> 9.10 would give something like:
>>>
>>> M.hs:8:10: warning: [-Wmissing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • This will become an error by default in a future GHC release;
>>>        use -Werror=severe to make severe warnings into errors now.
>>>
>>> Then in a future release:
>>>
>>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • Use -Wwarn=missing-methods to permit this anyway.
>>>
>>> Would that be a reasonable compromise?
>>>
>>> Adam
>>>
>>>
>>> On 19/09/2023 22:13, Joachim Breitner wrote:
>>> > Hi,
>>> >
>>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>>> >> Maybe implementing this "severe" category, but not changing its
>>> >> default to error, would get us some of the way there?  Then "best-
>>> >> practice guidance" could be "use -Werror=severe", and job done.
>>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>>> >> -Werror= ..." etc.
>>> >
>>> > anyone using `-Werror` would already get this behavior. So what is the
>>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>>> >
>>> >   -Werror, while great _during_ development or in leaf packages, is not
>>> >   is not good idea in _released_ code, i.e. code that is compiled by
>>> >   others, as that code needs to keep working even as compilers and
>>> >   dependencies change, such as libraries on hackage, or executables
>>> >   built by distro packagers.
>>> >   That’s why -Werror is frowned upon there.
>>> >
>>> >   But some changes in upstream packages _ought_ to cause compilation to
>>> >   fail, because they really need downstream code changes. These will
>>> >   cause severe warnings, and therefore -Werror=severe is desirable
>>> >   even for released code.
>>> >
>>> > Is that a good way of phrasing your thoughts there?
>>> >
>>> > It looks reasonable to me; if we think of deferable type error as
>>> > severe warnings, it totally fits this description: It would be
>>> > _possible_ to keep compiling the downstream code, but it would not be
>>> > desirable. That's why compilation fails, and that’s why we don’t defer
>>> > type errors by default.
>>> >
>>> > But if -Werror=severe is desirable generally, it would be unfortunate
>>> > if we cannot make it the default. If not right away, then maybe with a
>>> > suitable migration strategy? (Although I wonder if there are many users
>>> > out there that pay attention to deprecation warnings, e.g. watch
>>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>>> > about missing fields/methods already…)
>>> >
>>> >
>>> > Cheers,
>>> > Joachim
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>
>>> _______________________________________________
>>> 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/20230921/3b6f65fc/attachment-0001.html>

From vlad.z.4096 at gmail.com  Thu Sep 21 17:13:23 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Thu, 21 Sep 2023 19:13:23 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAHZ0NLrhySpMKkoDaLfCsL+P9H0tqu_e9B-Z8jUgOYDYABRZPQ@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <CABSB5jWeekoKYeKnAXQJLn5FPp6Knd2Y=dBACrPuhx-mprZG8w@mail.gmail.com>
 <CAHZ0NLrhySpMKkoDaLfCsL+P9H0tqu_e9B-Z8jUgOYDYABRZPQ@mail.gmail.com>
Message-ID: <CAHZ0NLqv-ZjWVatE4LdKaj0NEA4=icR1HdZOzkr=1UYspNh7kQ@mail.gmail.com>

In light of the recent discussion, I take that back. It turns out that type
inference is not the only problem with type-changing updates. There's also
an issue with multi-field type-changing updates, and it's more severe (I
don't see a clear way forward).

So now I'm now (weakly) in favor of the proposal as it is. SetField can't
handle type-changing updates -- so be it. We need a bigger hammer to deal
with type-changing updates.

Vlad

On Thu, Sep 21, 2023 at 11:12 AM Vladislav Zavialov <vlad.z.4096 at gmail.com>
wrote:

> I'm against the proposal in its current form because it does not support
> type-changing update and is not forward-compatible with it. Fortunately, it
> is not hard to fix this, as Adam points out in a GitHub comment:
>
> > I suppose one thing we could do now would be to add the parameters for
> type-changing update already, but restrict the constraint solver behaviour,
> e.g. define the classes SetField x s t a b and type SetField' x r a =
> SetField x r r a a, but have the constraint solver always unify s ~ t and a
> ~ b when solving constraints. That would limit (but not necessarily
> eliminate) the breakage when generalising the constraint solver.
>
> Let's do it this way to avoid a breaking change in the future!
>
> Vlad
>
> On Thu, Sep 21, 2023 at 10:35 AM Chris Dornan <chris at chrisdornan.com>
> wrote:
>
>> +1 from me
>>
>> On Thu, 21 Sep 2023 at 08:37, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all.
>>>
>>> I submitted my recommendation 3 weeks ago, and only Simon has commented
>>> yet. Please let me know your thoughts.
>>>
>>> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>>> Dear all,
>>>>
>>>> Don't forget to opine here. To reiterate, I really don't expect the
>>>> proposal to be controversial. The text of the proposal is rather long, but
>>>> is made easy to read. So it shouldn't take too much of your time.
>>>>
>>>> /Arnaud
>>>>
>>>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <
>>>> simon.peytonjones at gmail.com> wrote:
>>>>
>>>>> I support acceptance.
>>>>>
>>>>> Simon
>>>>>
>>>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>>>> wrote:
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> [ Proposal #583
>>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>>>>>>
>>>>>> Our own Adam proposes to amend the design of the highly experimental
>>>>>> OverloadedRecordUpdate extension as had been designed in proposal #158 [
>>>>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst
>>>>>> ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405
>>>>>> ].
>>>>>>
>>>>>> Specifically, Adam proposes a modification of the type classes that
>>>>>> would back the extension.
>>>>>>
>>>>>> In the previous design the HasField class is defined as a lens:
>>>>>>
>>>>>> class HasField (n :: k) r a | r n -> a
>>>>>>   hasField :: r -> (a -> r, a)
>>>>>>
>>>>>> The proposal is to replace it by two classes (slightly simplified)
>>>>>>
>>>>>> class HasField (n :: k) r a | r n -> a
>>>>>>   hasField :: r -> a
>>>>>>
>>>>>> class SetField (n::k) r a | r n -> a
>>>>>>   modifyField :: (a -> a) -> r -> a
>>>>>>   setField :: a -> r -> a
>>>>>>
>>>>>> This is originally motivated by some performance consideration: the
>>>>>> prototype implementation of HasField as a lens can be very time consuming
>>>>>> because instances of HasFields are generated eagerly at record definition
>>>>>> sites, whereas the simple HasField instances can simply reuse the selectors
>>>>>> already generated by GHC. But a lot of thoughts have been put into the new
>>>>>> design, and my summary can certainly not do it justice: the proposal is
>>>>>> very well argumented.
>>>>>>
>>>>>> A point I'll make here is that the new design is actually parametric
>>>>>> in the data representation of the field type. Something that wasn't
>>>>>> possible in the original design.
>>>>>>
>>>>>> This proposal is not technically backward compatible, because the
>>>>>> order of argument in which OverloadedRecordUpdate expects the argument of
>>>>>> setField is changed. This is not essential to the proposal, but this is a
>>>>>> more consistent order argument with the rest of Haskell. And considering
>>>>>> that OverloadedRecordUpdate is very loudly advertised as experimental, I
>>>>>> recommend accepting this breakage.
>>>>>>
>>>>>> Overall the proposal is actually more backward compatible with GHC
>>>>>> 9.8 than the original design, as the HasField class is left unchanged.
>>>>>>
>>>>>> Overall, the proposal looks quite reasonable to me, and well-argued.
>>>>>> I recommend acceptance.
>>>>>>
>>>>>> --
>>>>>> Arnaud Spiwack
>>>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>>> _______________________________________________
>>>>>> ghc-steering-committee mailing list
>>>>>> ghc-steering-committee at haskell.org
>>>>>>
>>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>>
>>>
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> 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/20230921/f110995e/attachment.html>

From mail at joachim-breitner.de  Thu Sep 21 17:20:54 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 21 Sep 2023 19:20:54 +0200
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
Message-ID: <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
> Dear all.
> 
> I submitted my recommendation 3 weeks ago, and only Simon has
> commented yet. Please let me know your thoughts.

I am essentially ignorant about anything related to records in Haskell,
and will recuse myself, trusting y’all about this.

Cheers,
Joachim

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


From moritz.angermann at gmail.com  Fri Sep 22 01:07:24 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 22 Sep 2023 09:07:24 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
Message-ID: <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>

I’m tempted to recuse myself as well on the technical merits of this
proposal. As others might already expect, I am concerned about this
breaking existing code. Do we have a rough estimate how much this will
break?

It also surfaces a topic we discussed just a short while ago. We have a
feature in a stable compiler release, which we consider experimental, and
thus reserve the right to break? I find this concept still fundamentally
flawed. Anything that is part of stable compiler releases has to be
considered stable by extension and thus needs to be treated with utmost
care.

I can see and fully support the wish to have a language reactor where
things can be experimented with. But if we have this in our stable
releases, it needs to be guarded in a way that users of those features have
to actively opt in to it. I have people seen adopting this feature already,
and I do not believe all of them are aware that this is a bleeding edge
feature that can break without notice at any point in time.

As there is supposedly a backwards compatible implementation for this, I’d
like to ask for this to be considered in two steps:
- backwards compatible change first.
- deprecation and change of syntax second.

Yes, this will be more work on behalf of the implementors. The burden of
change is on the implementors, we can’t expect our users to cover the costs.

For the second part, we should also have a thorough justification for the
need to break.

I’ll leave this with two links:
Simon Marlow’s recent comment:
https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
Dimitriis Tweet contrasting OCaml to Haskell:
https://x.com/chshersh/status/1704886633856696831?s=46

Best
 Moritz

On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
> > Dear all.
> >
> > I submitted my recommendation 3 weeks ago, and only Simon has
> > commented yet. Please let me know your thoughts.
>
> I am essentially ignorant about anything related to records in Haskell,
> and will recuse myself, trusting y’all about this.
>
> 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/20230922/2ace8eae/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Sep 22 07:44:33 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Sep 2023 08:44:33 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
 <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>
Message-ID: <CAJKmMz9_h2fQkn5QFiQyMo4B1u2NTo-f6i8uG7qmEKue0R2Qog@mail.gmail.com>

>
> We have a feature in a stable compiler release, which we consider
> experimental, and thus reserve the right to break?
>
I agree with this concern.

Until recently we didn't have ghc-experimental, so there was no boundary
between "experimental" and "stable".  In another GHC proposal we are
considering identifying "stable" extensions.  Once both of those things in
place we will have a clear line between things that we should really
hesitate before changing, and things that are advertised as experimental
and subject to change.

Overloaded record fields are in the latter group, but we have had no way to
advertise that fact.  I'd love us to be able to.

As there is supposedly a backwards compatible implementation for this, I’d
> like to ask for this to be considered in two steps:
> - backwards compatible change first.
> - deprecation and change of syntax second.
>

If that's possible, it sounds plausible.  Perhaps you can make the
suggestion on the main discussion thread, and Adam can respond?

Simon

On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I’m tempted to recuse myself as well on the technical merits of this
> proposal. As others might already expect, I am concerned about this
> breaking existing code. Do we have a rough estimate how much this will
> break?
>
> It also surfaces a topic we discussed just a short while ago. We have a
> feature in a stable compiler release, which we consider experimental, and
> thus reserve the right to break? I find this concept still fundamentally
> flawed. Anything that is part of stable compiler releases has to be
> considered stable by extension and thus needs to be treated with utmost
> care.
>
> I can see and fully support the wish to have a language reactor where
> things can be experimented with. But if we have this in our stable
> releases, it needs to be guarded in a way that users of those features have
> to actively opt in to it. I have people seen adopting this feature already,
> and I do not believe all of them are aware that this is a bleeding edge
> feature that can break without notice at any point in time.
>
> As there is supposedly a backwards compatible implementation for this, I’d
> like to ask for this to be considered in two steps:
> - backwards compatible change first.
> - deprecation and change of syntax second.
>
> Yes, this will be more work on behalf of the implementors. The burden of
> change is on the implementors, we can’t expect our users to cover the costs.
>
> For the second part, we should also have a thorough justification for the
> need to break.
>
> I’ll leave this with two links:
> Simon Marlow’s recent comment:
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
> Dimitriis Tweet contrasting OCaml to Haskell:
> https://x.com/chshersh/status/1704886633856696831?s=46
>
> Best
>  Moritz
>
> On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
>> > Dear all.
>> >
>> > I submitted my recommendation 3 weeks ago, and only Simon has
>> > commented yet. Please let me know your thoughts.
>>
>> I am essentially ignorant about anything related to records in Haskell,
>> and will recuse myself, trusting y’all about this.
>>
>> 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/20230922/337bccb0/attachment.html>

From moritz.angermann at gmail.com  Fri Sep 22 08:13:14 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 22 Sep 2023 16:13:14 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAJKmMz9_h2fQkn5QFiQyMo4B1u2NTo-f6i8uG7qmEKue0R2Qog@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
 <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>
 <CAJKmMz9_h2fQkn5QFiQyMo4B1u2NTo-f6i8uG7qmEKue0R2Qog@mail.gmail.com>
Message-ID: <CAKfdd-z65n=k6VYhW4qFyiyZV==yC_0PN3Ydas1Gdi6nW8jhog@mail.gmail.com>

>
>

> As there is supposedly a backwards compatible implementation for this, I’d
>> like to ask for this to be considered in two steps:
>> - backwards compatible change first.
>> - deprecation and change of syntax second.
>>
>
> If that's possible, it sounds plausible.  Perhaps you can make the
> suggestion on the main discussion thread, and Adam can respond?
>

The proposal already contains this suggestion if my reading is correct. The
breaking change is the reordering of parameters of setField. And lists
under the section “Order of arguments to setField”, that this proposal can
work without the reordering.

I am feeling quit uneasy arguing for this, as this option only came up due
to the proposal being written so thoroughly. The proposal also explicitly
notes that OverloadedRecordUpdate has been marked as experimental. In the
“Backward Compatibility” section.

While I still disagree that there can be any experimental features in a
stable release, I can see myself supporting this proposal if we
collectively work towards preventing this going forward. The General Rules
outlined in
https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
can be a good first step.

I’d still like to hear Simon Marlow’s thoughts on this after his plea for a
culture shift recently
https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html

Best,
  Moritz

On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> I’m tempted to recuse myself as well on the technical merits of this
>> proposal. As others might already expect, I am concerned about this
>> breaking existing code. Do we have a rough estimate how much this will
>> break?
>>
>> It also surfaces a topic we discussed just a short while ago. We have a
>> feature in a stable compiler release, which we consider experimental, and
>> thus reserve the right to break? I find this concept still fundamentally
>> flawed. Anything that is part of stable compiler releases has to be
>> considered stable by extension and thus needs to be treated with utmost
>> care.
>>
>> I can see and fully support the wish to have a language reactor where
>> things can be experimented with. But if we have this in our stable
>> releases, it needs to be guarded in a way that users of those features have
>> to actively opt in to it. I have people seen adopting this feature already,
>> and I do not believe all of them are aware that this is a bleeding edge
>> feature that can break without notice at any point in time.
>>
>> As there is supposedly a backwards compatible implementation for this,
>> I’d like to ask for this to be considered in two steps:
>> - backwards compatible change first.
>> - deprecation and change of syntax second.
>>
>> Yes, this will be more work on behalf of the implementors. The burden of
>> change is on the implementors, we can’t expect our users to cover the costs.
>>
>> For the second part, we should also have a thorough justification for the
>> need to break.
>>
>> I’ll leave this with two links:
>> Simon Marlow’s recent comment:
>>
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>> Dimitriis Tweet contrasting OCaml to Haskell:
>> https://x.com/chshersh/status/1704886633856696831?s=46
>>
>> Best
>>  Moritz
>>
>> On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <
>> mail at joachim-breitner.de> wrote:
>>
>>> Hi,
>>>
>>> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
>>> > Dear all.
>>> >
>>> > I submitted my recommendation 3 weeks ago, and only Simon has
>>> > commented yet. Please let me know your thoughts.
>>>
>>> I am essentially ignorant about anything related to records in Haskell,
>>> and will recuse myself, trusting y’all about this.
>>>
>>> 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/20230922/104c88ce/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Sep 22 08:32:45 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Sep 2023 09:32:45 +0100
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAKfdd-z65n=k6VYhW4qFyiyZV==yC_0PN3Ydas1Gdi6nW8jhog@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
 <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>
 <CAJKmMz9_h2fQkn5QFiQyMo4B1u2NTo-f6i8uG7qmEKue0R2Qog@mail.gmail.com>
 <CAKfdd-z65n=k6VYhW4qFyiyZV==yC_0PN3Ydas1Gdi6nW8jhog@mail.gmail.com>
Message-ID: <CAJKmMz9_iK4iEujNP=BDwgAz8TtsJUw6w2RL54yF5Gz3BN+Cmw@mail.gmail.com>

>
> The General Rules outlined in
> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
> can be a good first step.


I think that articulating some General Rules like this would help us a lot.

If we had #601 <https://github.com/ghc-proposals/ghc-proposals/pull/601>in
some form (it is back with the author for review), we would have a list of
extensions designated "stable", which we might treat differently to
extensions designated "experimental".  That would help too.

I realise that (GR1) is stronger than I intended: I think we need to allow
room to modify extensions designated "experimental" -- that's what
"experimental" means!

   - General rule (GR1): a GHC proposal should ensure that code that
   invokes only extensions designated "stable", and that compiles before the
   change, will continue compile after the change, given the same compiler
   flags
      - We exclude -Werror because otherwise (GR1) would be broken whenever
      we add a warning.
      - We exclude experimental extensions because those are (by
      definition) subject to change.
      - (GR1) is trivially satisfied if the change is gated behind an
      extension flag.
      - (GR1) is broken if, say, we turn a warning into an error

Is that acceptable?

PS: we should also agree that a "stable" extension should not require
dependencies on ghc-experimental.  To become stable, any library support
for an extension must move into `base`.

Moritz quotes Simon M saying

when considering the cost/benefit tradeoff adding a migration cycle doesn't
> reduce the cost, it just defers it.


I understood that as saying "don't bother with a deprecation cycle".  But I
understand Moritz as saying "please give us a deprecation cycle".  I don't
have a strong view myself but it would be good to achieve consensus on this
point.  I *think *(but I am not sure) that the consensus is:

   - Do have a deprecation cycle if possible.
   - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
   are as large as ever.

Simon

On Fri, 22 Sept 2023 at 09:13, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

>
>
>> As there is supposedly a backwards compatible implementation for this,
>>> I’d like to ask for this to be considered in two steps:
>>> - backwards compatible change first.
>>> - deprecation and change of syntax second.
>>>
>>
>> If that's possible, it sounds plausible.  Perhaps you can make the
>> suggestion on the main discussion thread, and Adam can respond?
>>
>
> The proposal already contains this suggestion if my reading is correct.
> The breaking change is the reordering of parameters of setField. And lists
> under the section “Order of arguments to setField”, that this proposal can
> work without the reordering.
>
> I am feeling quit uneasy arguing for this, as this option only came up due
> to the proposal being written so thoroughly. The proposal also explicitly
> notes that OverloadedRecordUpdate has been marked as experimental. In the
> “Backward Compatibility” section.
>
> While I still disagree that there can be any experimental features in a
> stable release, I can see myself supporting this proposal if we
> collectively work towards preventing this going forward. The General Rules
> outlined in
>
> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
> can be a good first step.
>
> I’d still like to hear Simon Marlow’s thoughts on this after his plea for
> a culture shift recently
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>
> Best,
>   Moritz
>
> On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> I’m tempted to recuse myself as well on the technical merits of this
>>> proposal. As others might already expect, I am concerned about this
>>> breaking existing code. Do we have a rough estimate how much this will
>>> break?
>>>
>>> It also surfaces a topic we discussed just a short while ago. We have a
>>> feature in a stable compiler release, which we consider experimental, and
>>> thus reserve the right to break? I find this concept still fundamentally
>>> flawed. Anything that is part of stable compiler releases has to be
>>> considered stable by extension and thus needs to be treated with utmost
>>> care.
>>>
>>> I can see and fully support the wish to have a language reactor where
>>> things can be experimented with. But if we have this in our stable
>>> releases, it needs to be guarded in a way that users of those features have
>>> to actively opt in to it. I have people seen adopting this feature already,
>>> and I do not believe all of them are aware that this is a bleeding edge
>>> feature that can break without notice at any point in time.
>>>
>>> As there is supposedly a backwards compatible implementation for this,
>>> I’d like to ask for this to be considered in two steps:
>>> - backwards compatible change first.
>>> - deprecation and change of syntax second.
>>>
>>> Yes, this will be more work on behalf of the implementors. The burden of
>>> change is on the implementors, we can’t expect our users to cover the costs.
>>>
>>> For the second part, we should also have a thorough justification for
>>> the need to break.
>>>
>>> I’ll leave this with two links:
>>> Simon Marlow’s recent comment:
>>>
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>>> Dimitriis Tweet contrasting OCaml to Haskell:
>>> https://x.com/chshersh/status/1704886633856696831?s=46
>>>
>>> Best
>>>  Moritz
>>>
>>> On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <
>>> mail at joachim-breitner.de> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
>>>> > Dear all.
>>>> >
>>>> > I submitted my recommendation 3 weeks ago, and only Simon has
>>>> > commented yet. Please let me know your thoughts.
>>>>
>>>> I am essentially ignorant about anything related to records in Haskell,
>>>> and will recuse myself, trusting y’all about this.
>>>>
>>>> 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/20230922/1030c850/attachment.html>

From moritz.angermann at gmail.com  Fri Sep 22 08:59:30 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 22 Sep 2023 16:59:30 +0800
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAJKmMz9_iK4iEujNP=BDwgAz8TtsJUw6w2RL54yF5Gz3BN+Cmw@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
 <93787ea90e0b4f3d9b9feb4b5da71dedaeaf3a62.camel@joachim-breitner.de>
 <CAKfdd-xUhy5UiQeSud97JKuaVDiGra+HB-N+8Q22g60AZDJe=A@mail.gmail.com>
 <CAJKmMz9_h2fQkn5QFiQyMo4B1u2NTo-f6i8uG7qmEKue0R2Qog@mail.gmail.com>
 <CAKfdd-z65n=k6VYhW4qFyiyZV==yC_0PN3Ydas1Gdi6nW8jhog@mail.gmail.com>
 <CAJKmMz9_iK4iEujNP=BDwgAz8TtsJUw6w2RL54yF5Gz3BN+Cmw@mail.gmail.com>
Message-ID: <CAKfdd-zBZaqgtAHpd1NUKehx5+BsLmsHQg8Uz45w8DRtrDqsug@mail.gmail.com>

Now, this is derailing the original discussion a bit, and I'm not sure how
far we want to take this. But, regarding @Simon Marlow <marlowsd at gmail.com>'s
comment

This is one cultural aspect of our community I'd like to shift: the
> expectation that it's OK to make breaking changes as long as you warn about
> them or go through a migration cycle. It just isn't! (and I speak as
> someone who used to make lots of changes, I'm now fully repentant!). That's
> not to say that we shouldn't ever change anything, but when considering the
> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
> just defers it.


I actually read this as we should stop having breaking changes to begin
with. And _if_ we
do have breaking changes, that deprecation does not change the need to
actually change
code (cost). As outlined in my reply to that, and @Richard Eisenberg
<lists at richarde.dev>'s observation, it
"smears" the cost. The--to me--_much_ bigger implication of deprecation
cycles is that we
_inform_ our _customers_ about upcoming changes _early_, instead of _after
the fact_. We
also give them ample time to react. Being by changing their code, or
raising their concerns.
Would the Simplified Subsumptions / Deep Subsumptions change have looked
differently?
As such I see deprecation cycles as orthogonal to the question if we should
have breaking
changes to begin with.

Thus I believe the following:

> - Do have a deprecation cycle if possible.
> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
> are as large as ever.


should be upgraded to:
- Preferably _no_ breaking changes.
- If breaking changes, then with a deprecation cycle, unless technically
infeasible.
- An understanding that any breaking change incurs significant costs.

Ocaml recently added multicore support, and they put tremendous effort into
making
sure it keeps backwards compatibility:
https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md

PS: we should also agree that a "stable" extension should not require
> dependencies on ghc-experimental.  To become stable, any library support
> for an extension must move into `base`.


This seems like a good idea, however I still remain that _experimental_
features should not be on-by-default in a stable compiler. Yes, ideally I'd
not even see them in a stable compiler, but I know this view is
contentious. The use of `ghc-experimental` should therefore be guarded by
`--std=experimental` as Julian suggested. That is a loud opt-in to
experimental features.

Best,
 Moritz

On Fri, 22 Sept 2023 at 16:33, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The General Rules outlined in
>> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
>> can be a good first step.
>
>
> I think that articulating some General Rules like this would help us a lot.
>
> If we had #601 <https://github.com/ghc-proposals/ghc-proposals/pull/601>in
> some form (it is back with the author for review), we would have a list of
> extensions designated "stable", which we might treat differently to
> extensions designated "experimental".  That would help too.
>
> I realise that (GR1) is stronger than I intended: I think we need to allow
> room to modify extensions designated "experimental" -- that's what
> "experimental" means!
>
>    - General rule (GR1): a GHC proposal should ensure that code that
>    invokes only extensions designated "stable", and that compiles before the
>    change, will continue compile after the change, given the same compiler
>    flags
>       - We exclude -Werror because otherwise (GR1) would be broken
>       whenever we add a warning.
>       - We exclude experimental extensions because those are (by
>       definition) subject to change.
>       - (GR1) is trivially satisfied if the change is gated behind an
>       extension flag.
>       - (GR1) is broken if, say, we turn a warning into an error
>
> Is that acceptable?
>
> PS: we should also agree that a "stable" extension should not require
> dependencies on ghc-experimental.  To become stable, any library support
> for an extension must move into `base`.
>
> Moritz quotes Simon M saying
>
> when considering the cost/benefit tradeoff adding a migration cycle
>> doesn't reduce the cost, it just defers it.
>
>
> I understood that as saying "don't bother with a deprecation cycle".  But
> I understand Moritz as saying "please give us a deprecation cycle".  I
> don't have a strong view myself but it would be good to achieve consensus
> on this point.  I *think *(but I am not sure) that the consensus is:
>
>    - Do have a deprecation cycle if possible.
>    - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>    but are as large as ever.
>
> Simon
>
> On Fri, 22 Sept 2023 at 09:13, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>>
>>
>>> As there is supposedly a backwards compatible implementation for this,
>>>> I’d like to ask for this to be considered in two steps:
>>>> - backwards compatible change first.
>>>> - deprecation and change of syntax second.
>>>>
>>>
>>> If that's possible, it sounds plausible.  Perhaps you can make the
>>> suggestion on the main discussion thread, and Adam can respond?
>>>
>>
>> The proposal already contains this suggestion if my reading is correct.
>> The breaking change is the reordering of parameters of setField. And lists
>> under the section “Order of arguments to setField”, that this proposal can
>> work without the reordering.
>>
>> I am feeling quit uneasy arguing for this, as this option only came up
>> due to the proposal being written so thoroughly. The proposal also
>> explicitly notes that OverloadedRecordUpdate has been marked as
>> experimental. In the “Backward Compatibility” section.
>>
>> While I still disagree that there can be any experimental features in a
>> stable release, I can see myself supporting this proposal if we
>> collectively work towards preventing this going forward. The General Rules
>> outlined in
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/571#issuecomment-1729218305
>> can be a good first step.
>>
>> I’d still like to hear Simon Marlow’s thoughts on this after his plea for
>> a culture shift recently
>>
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>>
>> Best,
>>   Moritz
>>
>> On Fri, 22 Sept 2023 at 02:07, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> I’m tempted to recuse myself as well on the technical merits of this
>>>> proposal. As others might already expect, I am concerned about this
>>>> breaking existing code. Do we have a rough estimate how much this will
>>>> break?
>>>>
>>>> It also surfaces a topic we discussed just a short while ago. We have a
>>>> feature in a stable compiler release, which we consider experimental, and
>>>> thus reserve the right to break? I find this concept still fundamentally
>>>> flawed. Anything that is part of stable compiler releases has to be
>>>> considered stable by extension and thus needs to be treated with utmost
>>>> care.
>>>>
>>>> I can see and fully support the wish to have a language reactor where
>>>> things can be experimented with. But if we have this in our stable
>>>> releases, it needs to be guarded in a way that users of those features have
>>>> to actively opt in to it. I have people seen adopting this feature already,
>>>> and I do not believe all of them are aware that this is a bleeding edge
>>>> feature that can break without notice at any point in time.
>>>>
>>>> As there is supposedly a backwards compatible implementation for this,
>>>> I’d like to ask for this to be considered in two steps:
>>>> - backwards compatible change first.
>>>> - deprecation and change of syntax second.
>>>>
>>>> Yes, this will be more work on behalf of the implementors. The burden
>>>> of change is on the implementors, we can’t expect our users to cover the
>>>> costs.
>>>>
>>>> For the second part, we should also have a thorough justification for
>>>> the need to break.
>>>>
>>>> I’ll leave this with two links:
>>>> Simon Marlow’s recent comment:
>>>>
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003432.html
>>>> Dimitriis Tweet contrasting OCaml to Haskell:
>>>> https://x.com/chshersh/status/1704886633856696831?s=46
>>>>
>>>> Best
>>>>  Moritz
>>>>
>>>> On Fri, 22 Sep 2023 at 1:21 AM, Joachim Breitner <
>>>> mail at joachim-breitner.de> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Am Donnerstag, dem 21.09.2023 um 09:37 +0200 schrieb Arnaud Spiwack:
>>>>> > Dear all.
>>>>> >
>>>>> > I submitted my recommendation 3 weeks ago, and only Simon has
>>>>> > commented yet. Please let me know your thoughts.
>>>>>
>>>>> I am essentially ignorant about anything related to records in Haskell,
>>>>> and will recuse myself, trusting y’all about this.
>>>>>
>>>>> 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/20230922/0d7b1998/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Sep 22 09:53:34 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Sep 2023 10:53:34 +0100
Subject: [ghc-steering-committee] Stability
Message-ID: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>

Dear GHC SC

To avoid derailing the debate about -Wsevere
<https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
and HasField redesign
<https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
I'm starting a new (email for now) thread about stability.

I have tried to articulate what I believe is an evolving consensus in this
document
<https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
.

If we converge, we'll turn that into a proper PR for the GHC proposal
process, although it has wider implications than just GHC proposals and we
should share with a broader audience.  But let's start with the steering
committee.

Any views?  You all have edit rights.

I think that the draft covers Moritz's and Julian's goals, at least that
was my intention.  I have pasted Moritz's last email below, for context.

Simon


========= Moritz's last email ============

Now, this is derailing the original discussion a bit, and I'm not sure how
far we want to take this. But, regarding @Simon Marlow <marlowsd at gmail.com>'s
comment

This is one cultural aspect of our community I'd like to shift: the
> expectation that it's OK to make breaking changes as long as you warn about
> them or go through a migration cycle. It just isn't! (and I speak as
> someone who used to make lots of changes, I'm now fully repentant!). That's
> not to say that we shouldn't ever change anything, but when considering the
> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
> just defers it.


I actually read this as we should stop having breaking changes to begin
with. And _if_ we
do have breaking changes, that deprecation does not change the need to
actually change
code (cost). As outlined in my reply to that, and @Richard Eisenberg
<lists at richarde.dev>'s observation, it
"smears" the cost. The--to me--_much_ bigger implication of deprecation
cycles is that we
_inform_ our _customers_ about upcoming changes _early_, instead of _after
the fact_. We
also give them ample time to react. Being by changing their code, or
raising their concerns.
Would the Simplified Subsumptions / Deep Subsumptions change have looked
differently?
As such I see deprecation cycles as orthogonal to the question if we should
have breaking
changes to begin with.

Thus I believe the following:

> - Do have a deprecation cycle if possible.
> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
> are as large as ever.


should be upgraded to:
- Preferably _no_ breaking changes.
- If breaking changes, then with a deprecation cycle, unless technically
infeasible.
- An understanding that any breaking change incurs significant costs.

Ocaml recently added multicore support, and they put tremendous effort into
making
sure it keeps backwards compatibility:
https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md

PS: we should also agree that a "stable" extension should not require
> dependencies on ghc-experimental.  To become stable, any library support
> for an extension must move into `base`.


This seems like a good idea, however I still remain that _experimental_
features should not be on-by-default in a stable compiler. Yes, ideally I'd
not even see them in a stable compiler, but I know this view is
contentious. The use of `ghc-experimental` should therefore be guarded by
`--std=experimental` as Julian suggested. That is a loud opt-in to
experimental features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230922/3dd0e520/attachment.html>

From marlowsd at gmail.com  Fri Sep 22 10:36:30 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 22 Sep 2023 11:36:30 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <010f018ab7cc081c-164e37b3-30a6-44bf-a477-9ec010271d04-000000@us-east-2.amazonses.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
 <010f018ab7cc081c-164e37b3-30a6-44bf-a477-9ec010271d04-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPJJXhjcGi032Z9XEJU3M-C-UnKUeYoGgZKe-L2jEHQoQg@mail.gmail.com>

On Thu, 21 Sept 2023 at 13:51, Richard Eisenberg <lists at richarde.dev> wrote:

> I will mull on the actual proposal (I feel there is a solution somewhere
> here that we haven't hit yet), but I wanted to respond to Simon M's comment
> about deferred cost: The migration cycle is more than just a deferment:
> it's a smearing. That is, if something breaks suddenly, everyone must
> upgrade in unison: hard. If something breaks slowly, then people can update
> their projects when they choose during the migration period: much easier.
> That difference might not affect an enterprise all that much, but I think
> it has a sizable impact on open-source developers.
>

Yes you're right, and I'm reluctant to further derail this thread but I
think it's important to note that as the volume of changes increases, the
cost of upgrades increases with it, and so the frequency of upgrades
reduces, which nullifies the benefits of smearing the cost of a change with
deprecations. Eventually, some customers are jumping over so many releases
at once that they miss all the intermediate deprecations. This is the
reality where I work, and I believe other companies too.

Cheers
Simon


> Richard
>
> On Sep 21, 2023, at 8:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> I might be an outlier here, but deferring the change to a later release
> and adding an intermediate warning doesn't make it any less bad.
>
> This is one cultural aspect of our community I'd like to shift: the
> expectation that it's OK to make breaking changes as long as you warn about
> them or go through a migration cycle. It just isn't! (and I speak as
> someone who used to make lots of changes, I'm now fully repentant!). That's
> not to say that we shouldn't ever change anything, but when considering the
> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
> just defers it.
>
> Cheers
> Simon
>
>
>
> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>
>> I agree with Joachim's position here.
>>
>> Having a -Wsevere group at all would be a good start, but the problem
>> with stopping at "best-practice guidance" rather than changing the
>> defaults is that it benefits only those who learn about and follow the
>> guidance. So it remains a footgun for newcomers.
>>
>> Regarding migration, given that GHC has issued these warnings by default
>> for some time, I don't think we need be too shy about upgrading their
>> severity. We could have -Wcompat imply -Werror=severe, but that
>> complicates the semantics of warning groups, and will help only those
>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>
>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>> in 9.10, and mention in the warning message that this will be an error
>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>> 9.10 would give something like:
>>
>> M.hs:8:10: warning: [-Wmissing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • This will become an error by default in a future GHC release;
>>        use -Werror=severe to make severe warnings into errors now.
>>
>> Then in a future release:
>>
>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>      • No explicit implementation for
>>          ‘<>’
>>      • In the instance declaration for ‘Semigroup T’
>>      • Warning: this may lead to an infinite loop or runtime exception.
>>      • Use -Wwarn=missing-methods to permit this anyway.
>>
>> Would that be a reasonable compromise?
>>
>> Adam
>>
>>
>> On 19/09/2023 22:13, Joachim Breitner wrote:
>> > Hi,
>> >
>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>> >> Maybe implementing this "severe" category, but not changing its
>> >> default to error, would get us some of the way there?  Then "best-
>> >> practice guidance" could be "use -Werror=severe", and job done.
>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>> >> -Werror= ..." etc.
>> >
>> > anyone using `-Werror` would already get this behavior. So what is the
>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>> >
>> >   -Werror, while great _during_ development or in leaf packages, is not
>> >   is not good idea in _released_ code, i.e. code that is compiled by
>> >   others, as that code needs to keep working even as compilers and
>> >   dependencies change, such as libraries on hackage, or executables
>> >   built by distro packagers.
>> >   That’s why -Werror is frowned upon there.
>> >
>> >   But some changes in upstream packages _ought_ to cause compilation to
>> >   fail, because they really need downstream code changes. These will
>> >   cause severe warnings, and therefore -Werror=severe is desirable
>> >   even for released code.
>> >
>> > Is that a good way of phrasing your thoughts there?
>> >
>> > It looks reasonable to me; if we think of deferable type error as
>> > severe warnings, it totally fits this description: It would be
>> > _possible_ to keep compiling the downstream code, but it would not be
>> > desirable. That's why compilation fails, and that’s why we don’t defer
>> > type errors by default.
>> >
>> > But if -Werror=severe is desirable generally, it would be unfortunate
>> > if we cannot make it the default. If not right away, then maybe with a
>> > suitable migration strategy? (Although I wonder if there are many users
>> > out there that pay attention to deprecation warnings, e.g. watch
>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>> > about missing fields/methods already…)
>> >
>> >
>> > Cheers,
>> > Joachim
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230922/dd95db25/attachment-0001.html>

From moritz.angermann at gmail.com  Fri Sep 22 10:47:01 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 22 Sep 2023 18:47:01 +0800
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <CANsrgPJJXhjcGi032Z9XEJU3M-C-UnKUeYoGgZKe-L2jEHQoQg@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
 <010f018ab7cc081c-164e37b3-30a6-44bf-a477-9ec010271d04-000000@us-east-2.amazonses.com>
 <CANsrgPJJXhjcGi032Z9XEJU3M-C-UnKUeYoGgZKe-L2jEHQoQg@mail.gmail.com>
Message-ID: <CAKfdd-xaeG0i=xCyffNuzVZ2Bn_0bEKThVbOg5tiGAaMYE+YHw@mail.gmail.com>

Just to provide backing to your claim @Simon Marlow <marlowsd at gmail.com>,
yes it is the same for us 8.10 -> 9.2 -> 9.6, we might effectively go 8.10
-> 9.6 due to performance regressions in 9.2. However, we do use a large
part of the hackage ecosystem, and various people _do_ use compilers other
than our production compiler in their respective projects CI setup. Thus
they _do_ see deprecations, and necessary migrations, _and_ also fix up
dependencies in the ecosystem. Thus the cost of upgrading is spread across
multiple people and a longer time horizon than trying to upgrade a rather
large _living_ codebase at once, by a small "upgrade" team.

I also believe that if switching out the compiler was more trivial, we'd be
trialing newer compilers much more frequently and quicker, and would be
adopting new compilers more frequently. After all, we contribute to those
compilers and would like to make use of our own contributions, instead of
having to backport them all the time.

On Fri, 22 Sept 2023 at 18:36, Simon Marlow <marlowsd at gmail.com> wrote:

> On Thu, 21 Sept 2023 at 13:51, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> I will mull on the actual proposal (I feel there is a solution somewhere
>> here that we haven't hit yet), but I wanted to respond to Simon M's comment
>> about deferred cost: The migration cycle is more than just a deferment:
>> it's a smearing. That is, if something breaks suddenly, everyone must
>> upgrade in unison: hard. If something breaks slowly, then people can update
>> their projects when they choose during the migration period: much easier.
>> That difference might not affect an enterprise all that much, but I think
>> it has a sizable impact on open-source developers.
>>
>
> Yes you're right, and I'm reluctant to further derail this thread but I
> think it's important to note that as the volume of changes increases, the
> cost of upgrades increases with it, and so the frequency of upgrades
> reduces, which nullifies the benefits of smearing the cost of a change with
> deprecations. Eventually, some customers are jumping over so many releases
> at once that they miss all the intermediate deprecations. This is the
> reality where I work, and I believe other companies too.
>
> Cheers
> Simon
>
>
>> Richard
>>
>> On Sep 21, 2023, at 8:34 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>>
>> I might be an outlier here, but deferring the change to a later release
>> and adding an intermediate warning doesn't make it any less bad.
>>
>> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!). That's
>> not to say that we shouldn't ever change anything, but when considering the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
>>
>> Cheers
>> Simon
>>
>>
>>
>> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> I agree with Joachim's position here.
>>>
>>> Having a -Wsevere group at all would be a good start, but the problem
>>> with stopping at "best-practice guidance" rather than changing the
>>> defaults is that it benefits only those who learn about and follow the
>>> guidance. So it remains a footgun for newcomers.
>>>
>>> Regarding migration, given that GHC has issued these warnings by default
>>> for some time, I don't think we need be too shy about upgrading their
>>> severity. We could have -Wcompat imply -Werror=severe, but that
>>> complicates the semantics of warning groups, and will help only those
>>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>>
>>> I suppose as Moritz suggests we could introduce and advertise -Wsevere
>>> in 9.10, and mention in the warning message that this will be an error
>>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so
>>> 9.10 would give something like:
>>>
>>> M.hs:8:10: warning: [-Wmissing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • This will become an error by default in a future GHC release;
>>>        use -Werror=severe to make severe warnings into errors now.
>>>
>>> Then in a future release:
>>>
>>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • Use -Wwarn=missing-methods to permit this anyway.
>>>
>>> Would that be a reasonable compromise?
>>>
>>> Adam
>>>
>>>
>>> On 19/09/2023 22:13, Joachim Breitner wrote:
>>> > Hi,
>>> >
>>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>>> >> Maybe implementing this "severe" category, but not changing its
>>> >> default to error, would get us some of the way there?  Then "best-
>>> >> practice guidance" could be "use -Werror=severe", and job done.
>>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>>> >> -Werror= ..." etc.
>>> >
>>> > anyone using `-Werror` would already get this behavior. So what is the
>>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>>> >
>>> >   -Werror, while great _during_ development or in leaf packages, is not
>>> >   is not good idea in _released_ code, i.e. code that is compiled by
>>> >   others, as that code needs to keep working even as compilers and
>>> >   dependencies change, such as libraries on hackage, or executables
>>> >   built by distro packagers.
>>> >   That’s why -Werror is frowned upon there.
>>> >
>>> >   But some changes in upstream packages _ought_ to cause compilation to
>>> >   fail, because they really need downstream code changes. These will
>>> >   cause severe warnings, and therefore -Werror=severe is desirable
>>> >   even for released code.
>>> >
>>> > Is that a good way of phrasing your thoughts there?
>>> >
>>> > It looks reasonable to me; if we think of deferable type error as
>>> > severe warnings, it totally fits this description: It would be
>>> > _possible_ to keep compiling the downstream code, but it would not be
>>> > desirable. That's why compilation fails, and that’s why we don’t defer
>>> > type errors by default.
>>> >
>>> > But if -Werror=severe is desirable generally, it would be unfortunate
>>> > if we cannot make it the default. If not right away, then maybe with a
>>> > suitable migration strategy? (Although I wonder if there are many users
>>> > out there that pay attention to deprecation warnings, e.g. watch
>>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>>> > about missing fields/methods already…)
>>> >
>>> >
>>> > Cheers,
>>> > Joachim
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>
>>> _______________________________________________
>>> 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/20230922/34ff1123/attachment.html>

From moritz.angermann at gmail.com  Fri Sep 22 10:47:43 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 22 Sep 2023 18:47:43 +0800
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
Message-ID: <CAKfdd-xn5KAyCyCzES1XdMQ=wtJ+4-eTw5uLMG6OJZRkLkc2AQ@mail.gmail.com>

Dear Simon,

I want to thank you for taking the initiative of formulating this policy!

Thank you!

Best,
 Moritz

On Fri, 22 Sept 2023 at 17:54, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC SC
>
> To avoid derailing the debate about -Wsevere
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
> and HasField redesign
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
> I'm starting a new (email for now) thread about stability.
>
> I have tried to articulate what I believe is an evolving consensus in
> this document
> <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
> .
>
> If we converge, we'll turn that into a proper PR for the GHC proposal
> process, although it has wider implications than just GHC proposals and we
> should share with a broader audience.  But let's start with the steering
> committee.
>
> Any views?  You all have edit rights.
>
> I think that the draft covers Moritz's and Julian's goals, at least that
> was my intention.  I have pasted Moritz's last email below, for context.
>
> Simon
>
>
> ========= Moritz's last email ============
>
> Now, this is derailing the original discussion a bit, and I'm not sure how
> far we want to take this. But, regarding @Simon Marlow
> <marlowsd at gmail.com>'s comment
>
> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn
>> about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!).
>> That's
>> not to say that we shouldn't ever change anything, but when considering
>> the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
>
>
> I actually read this as we should stop having breaking changes to begin
> with. And _if_ we
> do have breaking changes, that deprecation does not change the need to
> actually change
> code (cost). As outlined in my reply to that, and @Richard Eisenberg
> <lists at richarde.dev>'s observation, it
> "smears" the cost. The--to me--_much_ bigger implication of deprecation
> cycles is that we
> _inform_ our _customers_ about upcoming changes _early_, instead of _after
> the fact_. We
> also give them ample time to react. Being by changing their code, or
> raising their concerns.
> Would the Simplified Subsumptions / Deep Subsumptions change have looked
> differently?
> As such I see deprecation cycles as orthogonal to the question if we
> should have breaking
> changes to begin with.
>
> Thus I believe the following:
>
>> - Do have a deprecation cycle if possible.
>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
>> are as large as ever.
>
>
> should be upgraded to:
> - Preferably _no_ breaking changes.
> - If breaking changes, then with a deprecation cycle, unless technically
> infeasible.
> - An understanding that any breaking change incurs significant costs.
>
> Ocaml recently added multicore support, and they put tremendous effort
> into making
> sure it keeps backwards compatibility:
> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>
> PS: we should also agree that a "stable" extension should not require
>> dependencies on ghc-experimental.  To become stable, any library support
>> for an extension must move into `base`.
>
>
> This seems like a good idea, however I still remain that _experimental_
> features should not be on-by-default in a stable compiler. Yes, ideally I'd
> not even see them in a stable compiler, but I know this view is
> contentious. The use of `ghc-experimental` should therefore be guarded by
> `--std=experimental` as Julian suggested. That is a loud opt-in to
> experimental features.
> _______________________________________________
> 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/20230922/747f361b/attachment-0001.html>

From marlowsd at gmail.com  Fri Sep 22 10:50:40 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 22 Sep 2023 11:50:40 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
Message-ID: <CANsrgP+V_kT3DgF+sRwsbWjOMRP=Jk6q1QVjWnaoE+8BLOo2sg@mail.gmail.com>

I like it a lot! Did some minor editing and added a comment.

Cheers
Simon

On Fri, 22 Sept 2023 at 10:54, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC SC
>
> To avoid derailing the debate about -Wsevere
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
> and HasField redesign
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
> I'm starting a new (email for now) thread about stability.
>
> I have tried to articulate what I believe is an evolving consensus in
> this document
> <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
> .
>
> If we converge, we'll turn that into a proper PR for the GHC proposal
> process, although it has wider implications than just GHC proposals and we
> should share with a broader audience.  But let's start with the steering
> committee.
>
> Any views?  You all have edit rights.
>
> I think that the draft covers Moritz's and Julian's goals, at least that
> was my intention.  I have pasted Moritz's last email below, for context.
>
> Simon
>
>
> ========= Moritz's last email ============
>
> Now, this is derailing the original discussion a bit, and I'm not sure how
> far we want to take this. But, regarding @Simon Marlow
> <marlowsd at gmail.com>'s comment
>
> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn
>> about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!).
>> That's
>> not to say that we shouldn't ever change anything, but when considering
>> the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
>
>
> I actually read this as we should stop having breaking changes to begin
> with. And _if_ we
> do have breaking changes, that deprecation does not change the need to
> actually change
> code (cost). As outlined in my reply to that, and @Richard Eisenberg
> <lists at richarde.dev>'s observation, it
> "smears" the cost. The--to me--_much_ bigger implication of deprecation
> cycles is that we
> _inform_ our _customers_ about upcoming changes _early_, instead of _after
> the fact_. We
> also give them ample time to react. Being by changing their code, or
> raising their concerns.
> Would the Simplified Subsumptions / Deep Subsumptions change have looked
> differently?
> As such I see deprecation cycles as orthogonal to the question if we
> should have breaking
> changes to begin with.
>
> Thus I believe the following:
>
>> - Do have a deprecation cycle if possible.
>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
>> are as large as ever.
>
>
> should be upgraded to:
> - Preferably _no_ breaking changes.
> - If breaking changes, then with a deprecation cycle, unless technically
> infeasible.
> - An understanding that any breaking change incurs significant costs.
>
> Ocaml recently added multicore support, and they put tremendous effort
> into making
> sure it keeps backwards compatibility:
> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>
> PS: we should also agree that a "stable" extension should not require
>> dependencies on ghc-experimental.  To become stable, any library support
>> for an extension must move into `base`.
>
>
> This seems like a good idea, however I still remain that _experimental_
> features should not be on-by-default in a stable compiler. Yes, ideally I'd
> not even see them in a stable compiler, but I know this view is
> contentious. The use of `ghc-experimental` should therefore be guarded by
> `--std=experimental` as Julian suggested. That is a loud opt-in to
> experimental features.
> _______________________________________________
> 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/20230922/dd2d8cec/attachment.html>

From chris at chrisdornan.com  Fri Sep 22 11:16:01 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 22 Sep 2023 12:16:01 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
 <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>
Message-ID: <AFC83507-E642-40A1-A703-15C34B8AD0BA@chrisdornan.com>

Moritz, can I pass on some excellent advice I got from Richard on first joining the list, namely don't try to 'read the room' here but call things as you see them. Thanks to some excellent management from the usual suspects we are quite good at searching out a consensus when needed.

I am strongly in agreement with Simon Marlow here -- I really don't think we should be introducing breaking changes unless it is really, really necessary, and I just don't think "this is what we think developers should be doing" and "nobody reads manuals any more" clears the threshold for me. And, while I take Richard's point about the value of deprecation periods, I still think we should only introduce breaking changes in exceptional circumstances.

Again, I fully support the introduction of the Severe category with the proposed warnings included. 

The way I would approach this is to predicate the change of behaviour on a language extension with a view to getting it included in (say) GHC2024. People that really care about stability can tie things down by specifying the language they are working with at the appropriate points. Folks are now used to the GHC selecting a new default once a new Haskell* or GHC* standard is agreed.

Chris
 

> On 21 Sep 2023, at 14:13, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Thank you Simon! 
> 
> I think this raises a good point, in that _any_ breaking change should stand well on its own wrt to a cost/benefit analysis.
> 
> I’m not sure if we disagree or not.  I’ve assumed that the majority wants to make these changes.  I also often do not feel sufficiently capable enough to make a convincing argument against a specific change. 
> 
> Thus under the assumption that we are going to make a breaking change (because the majority want this), I feel very strongly about informing end users beforehand as well as the quality control aspect of being able to run regression tests by just swapping out the compiler trivially.
> 
> Thus *if* we are making a breaking change, I do not believe that a migration phase reduces the costs much (you still need to adjust your code), but I consider a breaking change without migration phase to be significantly worse to a breaking change with migration phase.
> 
> The difference for me practically lies in the following:
> If we migrate to a new compiler, a team of engineers start doing the initial migration for us (this means adding the new compiler to CI, and making sure existing code at least builds), this happens for multiple projects/components in dependency order.
> 
> After this has happened the project/component teams use the new compiler and fix their code.
> 
> If we have migration warnings for upcoming breaking changes, the work shifts from the new-compiler-across-multiple-projects team into the project teams.
> 
> This makes the whole add new compiler process significantly faster, and means less friction. It also means the project teams who have much better knowledge of their specific project can address the warnings better than the migration team which has to dig deep into existing code bases, get familiar with the code to make the necessity adjustments (or request pair sessions that take time from other tasks).
> 
> It also gives one more opportunity for the community to raise their hand and say, oh hell no, that’s a stupid idea; I’m going to complain about this! (I’ve been told this more than once; migration phases could also be seen as community inquiery, to get feedback from actual practitioners).
> 
> After writing this all down, I guess my push for “if breaking change, then only with migration phase” is orthogonal to “should we have breaking changes to begin with?”
> 
> Cheers,
>   Moritz
> 
> On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
>> I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.
>> 
>> This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.
>> 
>> Cheers
>> Simon
>> 
>> 
>> 
>> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>> I agree with Joachim's position here.
>>> 
>>> Having a -Wsevere group at all would be a good start, but the problem 
>>> with stopping at "best-practice guidance" rather than changing the 
>>> defaults is that it benefits only those who learn about and follow the 
>>> guidance. So it remains a footgun for newcomers.
>>> 
>>> Regarding migration, given that GHC has issued these warnings by default 
>>> for some time, I don't think we need be too shy about upgrading their 
>>> severity. We could have -Wcompat imply -Werror=severe, but that 
>>> complicates the semantics of warning groups, and will help only those 
>>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>> 
>>> I suppose as Moritz suggests we could introduce and advertise -Wsevere 
>>> in 9.10, and mention in the warning message that this will be an error 
>>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 
>>> 9.10 would give something like:
>>> 
>>> M.hs:8:10: warning: [-Wmissing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • This will become an error by default in a future GHC release;
>>>        use -Werror=severe to make severe warnings into errors now.
>>> 
>>> Then in a future release:
>>> 
>>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>>      • No explicit implementation for
>>>          ‘<>’
>>>      • In the instance declaration for ‘Semigroup T’
>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>      • Use -Wwarn=missing-methods to permit this anyway.
>>> 
>>> Would that be a reasonable compromise?
>>> 
>>> Adam
>>> 
>>> 
>>> On 19/09/2023 22:13, Joachim Breitner wrote:
>>> > Hi,
>>> > 
>>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>>> >> Maybe implementing this "severe" category, but not changing its
>>> >> default to error, would get us some of the way there?  Then "best-
>>> >> practice guidance" could be "use -Werror=severe", and job done.
>>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>>> >> -Werror= ..." etc.
>>> > 
>>> > anyone using `-Werror` would already get this behavior. So what is the
>>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>>> > 
>>> >   -Werror, while great _during_ development or in leaf packages, is not
>>> >   is not good idea in _released_ code, i.e. code that is compiled by
>>> >   others, as that code needs to keep working even as compilers and
>>> >   dependencies change, such as libraries on hackage, or executables
>>> >   built by distro packagers.
>>> >   That’s why -Werror is frowned upon there.
>>> > 
>>> >   But some changes in upstream packages _ought_ to cause compilation to
>>> >   fail, because they really need downstream code changes. These will
>>> >   cause severe warnings, and therefore -Werror=severe is desirable
>>> >   even for released code.
>>> > 
>>> > Is that a good way of phrasing your thoughts there?
>>> > 
>>> > It looks reasonable to me; if we think of deferable type error as
>>> > severe warnings, it totally fits this description: It would be
>>> > _possible_ to keep compiling the downstream code, but it would not be
>>> > desirable. That's why compilation fails, and that’s why we don’t defer
>>> > type errors by default.
>>> > 
>>> > But if -Werror=severe is desirable generally, it would be unfortunate
>>> > if we cannot make it the default. If not right away, then maybe with a
>>> > suitable migration strategy? (Although I wonder if there are many users
>>> > out there that pay attention to deprecation warnings, e.g. watch
>>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>>> > about missing fields/methods already…)
>>> > 
>>> > 
>>> > Cheers,
>>> > Joachim
>>> 
>>> -- 
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>> 
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> 
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> 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/20230922/4a1635be/attachment-0001.html>

From chris at chrisdornan.com  Fri Sep 22 11:38:51 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 22 Sep 2023 12:38:51 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
Message-ID: <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>

I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).

Chris

> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Dear GHC SC
> 
> To avoid derailing the debate about -Wsevere <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
> 
> I have tried to articulate what I believe is an evolving consensus in this document <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
> 
> If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience.  But let's start with the steering committee.
> 
> Any views?  You all have edit rights.
> 
> I think that the draft covers Moritz's and Julian's goals, at least that was my intention.  I have pasted Moritz's last email below, for context.
> 
> Simon
> 
> 
> ========= Moritz's last email ============
> 
> Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding @Simon Marlow <mailto:marlowsd at gmail.com>'s comment
> 
>> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!). That's
>> not to say that we shouldn't ever change anything, but when considering the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
> 
> I actually read this as we should stop having breaking changes to begin with. And _if_ we
> do have breaking changes, that deprecation does not change the need to actually change
> code (cost). As outlined in my reply to that, and @Richard Eisenberg <mailto:lists at richarde.dev>'s observation, it 
> "smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we
> _inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We
> also give them ample time to react. Being by changing their code, or raising their concerns.
> Would the Simplified Subsumptions / Deep Subsumptions change have looked differently?
> As such I see deprecation cycles as orthogonal to the question if we should have breaking
> changes to begin with.
> 
> Thus I believe the following:
>> - Do have a deprecation cycle if possible.
>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but are as large as ever.
> 
> should be upgraded to:
> - Preferably _no_ breaking changes.
> - If breaking changes, then with a deprecation cycle, unless technically infeasible.
> - An understanding that any breaking change incurs significant costs.
> 
> Ocaml recently added multicore support, and they put tremendous effort into making
> sure it keeps backwards compatibility: https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
> 
>> PS: we should also agree that a "stable" extension should not require dependencies on ghc-experimental.  To become stable, any library support for an extension must move into `base`.
> 
> This seems like a good idea, however I still remain that _experimental_ features should not be on-by-default in a stable compiler. Yes, ideally I'd not even see them in a stable compiler, but I know this view is contentious. The use of `ghc-experimental` should therefore be guarded by `--std=experimental` as Julian suggested. That is a loud opt-in to experimental features.
> _______________________________________________
> 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/20230922/f72c64d1/attachment.html>

From simon.peytonjones at gmail.com  Fri Sep 22 12:08:17 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Sep 2023 13:08:17 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>
Message-ID: <CAJKmMz--iPmmG1qUn+HDQZQQm2gw-ppHnArsbPCkJXJZnLojVQ@mail.gmail.com>

>
> I liked it all the way down to GR3, which, for me, simply undermines GR1.
> Everybody who wants to make a breaking change has a good reason to make the
> change (at least in the minds of its adherents).


Can you elaborate? I don't understand.  GR3 says simply "if you have a
compelling (GR2) reason to break (GR1) then do whatever you can to mitigate
the impact via a deprecation cycle".  Why does that undermine GR1?

Maybe you can rephrase (GR3)?

Simon


On Fri, 22 Sept 2023 at 12:39, Chris Dornan <chris at chrisdornan.com> wrote:

> I liked it all the way down to GR3, which, for me, simply undermines GR1.
> Everybody who wants to make a breaking change has a good reason to make the
> change (at least in the minds of its adherents).
>
> Chris
>
> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Dear GHC SC
>
> To avoid derailing the debate about -Wsevere
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
> and HasField redesign
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
> I'm starting a new (email for now) thread about stability.
>
> I have tried to articulate what I believe is an evolving consensus in
> this document
> <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
> .
>
> If we converge, we'll turn that into a proper PR for the GHC proposal
> process, although it has wider implications than just GHC proposals and we
> should share with a broader audience.  But let's start with the steering
> committee.
>
> Any views?  You all have edit rights.
>
> I think that the draft covers Moritz's and Julian's goals, at least that
> was my intention.  I have pasted Moritz's last email below, for context.
>
> Simon
>
>
> ========= Moritz's last email ============
>
> Now, this is derailing the original discussion a bit, and I'm not sure how
> far we want to take this. But, regarding @Simon Marlow
> <marlowsd at gmail.com>'s comment
>
> This is one cultural aspect of our community I'd like to shift: the
>> expectation that it's OK to make breaking changes as long as you warn
>> about
>> them or go through a migration cycle. It just isn't! (and I speak as
>> someone who used to make lots of changes, I'm now fully repentant!).
>> That's
>> not to say that we shouldn't ever change anything, but when considering
>> the
>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>> just defers it.
>
>
> I actually read this as we should stop having breaking changes to begin
> with. And _if_ we
> do have breaking changes, that deprecation does not change the need to
> actually change
> code (cost). As outlined in my reply to that, and @Richard Eisenberg
> <lists at richarde.dev>'s observation, it
> "smears" the cost. The--to me--_much_ bigger implication of deprecation
> cycles is that we
> _inform_ our _customers_ about upcoming changes _early_, instead of _after
> the fact_. We
> also give them ample time to react. Being by changing their code, or
> raising their concerns.
> Would the Simplified Subsumptions / Deep Subsumptions change have looked
> differently?
> As such I see deprecation cycles as orthogonal to the question if we
> should have breaking
> changes to begin with.
>
> Thus I believe the following:
>
>> - Do have a deprecation cycle if possible.
>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
>> are as large as ever.
>
>
> should be upgraded to:
> - Preferably _no_ breaking changes.
> - If breaking changes, then with a deprecation cycle, unless technically
> infeasible.
> - An understanding that any breaking change incurs significant costs.
>
> Ocaml recently added multicore support, and they put tremendous effort
> into making
> sure it keeps backwards compatibility:
> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>
> PS: we should also agree that a "stable" extension should not require
>> dependencies on ghc-experimental.  To become stable, any library support
>> for an extension must move into `base`.
>
>
> This seems like a good idea, however I still remain that _experimental_
> features should not be on-by-default in a stable compiler. Yes, ideally I'd
> not even see them in a stable compiler, but I know this view is
> contentious. The use of `ghc-experimental` should therefore be guarded by
> `--std=experimental` as Julian suggested. That is a loud opt-in to
> experimental features.
> _______________________________________________
> 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/20230922/d07cb1c1/attachment-0001.html>

From chris at chrisdornan.com  Fri Sep 22 15:58:31 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 22 Sep 2023 16:58:31 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz--iPmmG1qUn+HDQZQQm2gw-ppHnArsbPCkJXJZnLojVQ@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>
 <CAJKmMz--iPmmG1qUn+HDQZQQm2gw-ppHnArsbPCkJXJZnLojVQ@mail.gmail.com>
Message-ID: <F9E5F07C-FE31-4670-AEF4-5C1C10B3A871@chrisdornan.com>

I have added a comment in the doc saying a bit more, but I strongly believe we have to forswear, ever, electively introducing breaking changes inside such a proposed stability framework.

Something might happen to force us to make a change but such contingencies are covered by the current text.

Of course, experimental extensions can be subject to change, but this should, wherever possible, be done across deprecation cycles.

Any other changes will simply fall outside this framework and should have to be argued for as such.

I feel sure that we have enough tools at our disposal to make this work (see, for example, my suggestion for establishing #571 -Wsevere warnings as errors by default by capturing the behaviour in a language extension and rolling it into a future language standard).

Chris


> On 22 Sep 2023, at 13:08, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).
> 
> Can you elaborate? I don't understand.  GR3 says simply "if you have a compelling (GR2) reason to break (GR1) then do whatever you can to mitigate the impact via a deprecation cycle".  Why does that undermine GR1?
> 
> Maybe you can rephrase (GR3)?
> 
> Simon
> 
> 
> On Fri, 22 Sept 2023 at 12:39, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).
>> 
>> Chris
>> 
>>> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>> Dear GHC SC
>>> 
>>> To avoid derailing the debate about -Wsevere <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
>>> 
>>> I have tried to articulate what I believe is an evolving consensus in this document <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
>>> 
>>> If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience.  But let's start with the steering committee.
>>> 
>>> Any views?  You all have edit rights.
>>> 
>>> I think that the draft covers Moritz's and Julian's goals, at least that was my intention.  I have pasted Moritz's last email below, for context.
>>> 
>>> Simon
>>> 
>>> 
>>> ========= Moritz's last email ============
>>> 
>>> Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding @Simon Marlow <mailto:marlowsd at gmail.com>'s comment
>>> 
>>>> This is one cultural aspect of our community I'd like to shift: the
>>>> expectation that it's OK to make breaking changes as long as you warn about
>>>> them or go through a migration cycle. It just isn't! (and I speak as
>>>> someone who used to make lots of changes, I'm now fully repentant!). That's
>>>> not to say that we shouldn't ever change anything, but when considering the
>>>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>>>> just defers it.
>>> 
>>> I actually read this as we should stop having breaking changes to begin with. And _if_ we
>>> do have breaking changes, that deprecation does not change the need to actually change
>>> code (cost). As outlined in my reply to that, and @Richard Eisenberg <mailto:lists at richarde.dev>'s observation, it 
>>> "smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we
>>> _inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We
>>> also give them ample time to react. Being by changing their code, or raising their concerns.
>>> Would the Simplified Subsumptions / Deep Subsumptions change have looked differently?
>>> As such I see deprecation cycles as orthogonal to the question if we should have breaking
>>> changes to begin with.
>>> 
>>> Thus I believe the following:
>>>> - Do have a deprecation cycle if possible.
>>>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but are as large as ever.
>>> 
>>> should be upgraded to:
>>> - Preferably _no_ breaking changes.
>>> - If breaking changes, then with a deprecation cycle, unless technically infeasible.
>>> - An understanding that any breaking change incurs significant costs.
>>> 
>>> Ocaml recently added multicore support, and they put tremendous effort into making
>>> sure it keeps backwards compatibility: https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>> 
>>>> PS: we should also agree that a "stable" extension should not require dependencies on ghc-experimental.  To become stable, any library support for an extension must move into `base`.
>>> 
>>> This seems like a good idea, however I still remain that _experimental_ features should not be on-by-default in a stable compiler. Yes, ideally I'd not even see them in a stable compiler, but I know this view is contentious. The use of `ghc-experimental` should therefore be guarded by `--std=experimental` as Julian suggested. That is a loud opt-in to experimental features.
>>> _______________________________________________
>>> 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/20230922/a4f207cb/attachment.html>

From simon.peytonjones at gmail.com  Fri Sep 22 16:32:30 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 22 Sep 2023 17:32:30 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <F9E5F07C-FE31-4670-AEF4-5C1C10B3A871@chrisdornan.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>
 <CAJKmMz--iPmmG1qUn+HDQZQQm2gw-ppHnArsbPCkJXJZnLojVQ@mail.gmail.com>
 <F9E5F07C-FE31-4670-AEF4-5C1C10B3A871@chrisdornan.com>
Message-ID: <CAJKmMz_AgxTLyT=A6265tiRxRJz=pkba+hRGqFwy7aqKq3WhNw@mail.gmail.com>

>
> I have added a comment in the doc saying a bit more, but I strongly
> believe we have to forswear, ever, electively introducing breaking changes
> inside such a proposed stability framework.
>

I feel I'm still misunderstanding you.

Are you *really *saying that if we discover that (3+4) returns 8 we should
forswear, ever, fixing that bug?   (Fixing it is a breaking change.)
Surely not.

To take a slightly less caricature example, are you saying that we should
never have done simple subsumption, but forever adopted deep subsumption,
accepting the semantic unsoundness and technical debt that we would thereby
accumulate, forever.  Surely not?

I don't think I'm ready to forswear breaking (GR1).  But I agree that there
should be a compelling reason.

Maybe when you say "we should qualify it sufficiently that it is never
broken", you mean that (GR1) should say

General rule (GR1).  A stable Haskell program that works today should
continue to work in subsequent releases of GHC, *unless (GR2) applies*.


Then, technically, breaking a stable program for a compelling reason
doesn't break (GR1). But that's a bit of distinction without a difference!

Simon



On Fri, 22 Sept 2023 at 16:58, Chris Dornan <chris at chrisdornan.com> wrote:

> I have added a comment in the doc saying a bit more, but I strongly
> believe we have to forswear, ever, electively introducing breaking changes
> inside such a proposed stability framework.
>
> Something might happen to force us to make a change but such contingencies
> are covered by the current text.
>
> Of course, experimental extensions can be subject to change, but this
> should, wherever possible, be done across deprecation cycles.
>
> Any other changes will simply fall outside this framework and should have
> to be argued for as such.
>
> I feel sure that we have enough tools at our disposal to make this work
> (see, for example, my suggestion for establishing #571 -Wsevere warnings as
> errors by default by capturing the behaviour in a language extension and
> rolling it into a future language standard).
>
> Chris
>
>
> On 22 Sep 2023, at 13:08, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> I liked it all the way down to GR3, which, for me, simply undermines GR1.
>> Everybody who wants to make a breaking change has a good reason to make the
>> change (at least in the minds of its adherents).
>
>
> Can you elaborate? I don't understand.  GR3 says simply "if you have a
> compelling (GR2) reason to break (GR1) then do whatever you can to mitigate
> the impact via a deprecation cycle".  Why does that undermine GR1?
>
> Maybe you can rephrase (GR3)?
>
> Simon
>
>
> On Fri, 22 Sept 2023 at 12:39, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> I liked it all the way down to GR3, which, for me, simply undermines GR1.
>> Everybody who wants to make a breaking change has a good reason to make the
>> change (at least in the minds of its adherents).
>>
>> Chris
>>
>> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com>
>> wrote:
>>
>> Dear GHC SC
>>
>> To avoid derailing the debate about -Wsevere
>> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>> and HasField redesign
>> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>> I'm starting a new (email for now) thread about stability.
>>
>> I have tried to articulate what I believe is an evolving consensus in
>> this document
>> <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>
>> .
>>
>> If we converge, we'll turn that into a proper PR for the GHC proposal
>> process, although it has wider implications than just GHC proposals and we
>> should share with a broader audience.  But let's start with the steering
>> committee.
>>
>> Any views?  You all have edit rights.
>>
>> I think that the draft covers Moritz's and Julian's goals, at least that
>> was my intention.  I have pasted Moritz's last email below, for context.
>>
>> Simon
>>
>>
>> ========= Moritz's last email ============
>>
>> Now, this is derailing the original discussion a bit, and I'm not sure
>> how far we want to take this. But, regarding @Simon Marlow
>> <marlowsd at gmail.com>'s comment
>>
>> This is one cultural aspect of our community I'd like to shift: the
>>> expectation that it's OK to make breaking changes as long as you warn
>>> about
>>> them or go through a migration cycle. It just isn't! (and I speak as
>>> someone who used to make lots of changes, I'm now fully repentant!).
>>> That's
>>> not to say that we shouldn't ever change anything, but when considering
>>> the
>>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost,
>>> it
>>> just defers it.
>>
>>
>> I actually read this as we should stop having breaking changes to begin
>> with. And _if_ we
>> do have breaking changes, that deprecation does not change the need to
>> actually change
>> code (cost). As outlined in my reply to that, and @Richard Eisenberg
>> <lists at richarde.dev>'s observation, it
>> "smears" the cost. The--to me--_much_ bigger implication of deprecation
>> cycles is that we
>> _inform_ our _customers_ about upcoming changes _early_, instead of
>> _after the fact_. We
>> also give them ample time to react. Being by changing their code, or
>> raising their concerns.
>> Would the Simplified Subsumptions / Deep Subsumptions change have looked
>> differently?
>> As such I see deprecation cycles as orthogonal to the question if we
>> should have breaking
>> changes to begin with.
>>
>> Thus I believe the following:
>>
>>> - Do have a deprecation cycle if possible.
>>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but
>>> are as large as ever.
>>
>>
>> should be upgraded to:
>> - Preferably _no_ breaking changes.
>> - If breaking changes, then with a deprecation cycle, unless technically
>> infeasible.
>> - An understanding that any breaking change incurs significant costs.
>>
>> Ocaml recently added multicore support, and they put tremendous effort
>> into making
>> sure it keeps backwards compatibility:
>> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>
>> PS: we should also agree that a "stable" extension should not require
>>> dependencies on ghc-experimental.  To become stable, any library support
>>> for an extension must move into `base`.
>>
>>
>> This seems like a good idea, however I still remain that _experimental_
>> features should not be on-by-default in a stable compiler. Yes, ideally I'd
>> not even see them in a stable compiler, but I know this view is
>> contentious. The use of `ghc-experimental` should therefore be guarded by
>> `--std=experimental` as Julian suggested. That is a loud opt-in to
>> experimental features.
>> _______________________________________________
>> 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/20230922/b5cb9a14/attachment-0001.html>

From chris at chrisdornan.com  Sat Sep 23 04:15:37 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sat, 23 Sep 2023 05:15:37 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz_AgxTLyT=A6265tiRxRJz=pkba+hRGqFwy7aqKq3WhNw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <97D6F34D-12E2-40C8-84C7-1EBE5559367F@chrisdornan.com>
 <CAJKmMz--iPmmG1qUn+HDQZQQm2gw-ppHnArsbPCkJXJZnLojVQ@mail.gmail.com>
 <F9E5F07C-FE31-4670-AEF4-5C1C10B3A871@chrisdornan.com>
 <CAJKmMz_AgxTLyT=A6265tiRxRJz=pkba+hRGqFwy7aqKq3WhNw@mail.gmail.com>
Message-ID: <A09DDD72-F527-41DF-9658-54107B454649@chrisdornan.com>

I have no problem at all with GR2, which covers the kind of unforeseen exceptional cases (3+4==>8, deep subsumption) we will need to be able to change.

My confusion comes in interpreting GR3 -- I gained the impression that GR1, GR2 and GR3 are describing the various constraints on the changes that can be made with GR3 stipulating that if you need to break GR1 then this should be done with deprecation cycles.

If GR3 is merely stipulating the way that GR2 changes should be rolled out (circumstances permitting) then I have no objection to GR3 at all -- except to suggest that it be tweaked to make it it explicit that it is elaborating on how GR2 changes should be deployed.

I have refrained from making any changes to the text until I am sure I understand what we wish to convey.

Chris


> On 22 Sep 2023, at 17:32, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I have added a comment in the doc saying a bit more, but I strongly believe we have to forswear, ever, electively introducing breaking changes inside such a proposed stability framework. 
> 
> I feel I'm still misunderstanding you.
> 
> Are you really saying that if we discover that (3+4) returns 8 we should forswear, ever, fixing that bug?   (Fixing it is a breaking change.)   Surely not.  
> 
> To take a slightly less caricature example, are you saying that we should never have done simple subsumption, but forever adopted deep subsumption, accepting the semantic unsoundness and technical debt that we would thereby accumulate, forever.  Surely not?
> 
> I don't think I'm ready to forswear breaking (GR1).  But I agree that there should be a compelling reason.
> 
> Maybe when you say "we should qualify it sufficiently that it is never broken", you mean that (GR1) should say
> 
> General rule (GR1).  A stable Haskell program that works today should continue to work in subsequent releases of GHC, unless (GR2) applies.
> 
> Then, technically, breaking a stable program for a compelling reason doesn't break (GR1).  But that's a bit of distinction without a difference!
> 
> Simon
> 
> 
> 
> On Fri, 22 Sept 2023 at 16:58, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have added a comment in the doc saying a bit more, but I strongly believe we have to forswear, ever, electively introducing breaking changes inside such a proposed stability framework.
>> 
>> Something might happen to force us to make a change but such contingencies are covered by the current text.
>> 
>> Of course, experimental extensions can be subject to change, but this should, wherever possible, be done across deprecation cycles.
>> 
>> Any other changes will simply fall outside this framework and should have to be argued for as such.
>> 
>> I feel sure that we have enough tools at our disposal to make this work (see, for example, my suggestion for establishing #571 -Wsevere warnings as errors by default by capturing the behaviour in a language extension and rolling it into a future language standard).
>> 
>> Chris
>> 
>> 
>>> On 22 Sep 2023, at 13:08, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> 
>>>> I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).
>>> 
>>> Can you elaborate? I don't understand.  GR3 says simply "if you have a compelling (GR2) reason to break (GR1) then do whatever you can to mitigate the impact via a deprecation cycle".  Why does that undermine GR1?
>>> 
>>> Maybe you can rephrase (GR3)?
>>> 
>>> Simon
>>> 
>>> 
>>> On Fri, 22 Sept 2023 at 12:39, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>>>> I liked it all the way down to GR3, which, for me, simply undermines GR1. Everybody who wants to make a breaking change has a good reason to make the change (at least in the minds of its adherents).
>>>> 
>>>> Chris
>>>> 
>>>>> On 22 Sep 2023, at 10:53, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>> 
>>>>> Dear GHC SC
>>>>> 
>>>>> To avoid derailing the debate about -Wsevere <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
>>>>> 
>>>>> I have tried to articulate what I believe is an evolving consensus in this document <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
>>>>> 
>>>>> If we converge, we'll turn that into a proper PR for the GHC proposal process, although it has wider implications than just GHC proposals and we should share with a broader audience.  But let's start with the steering committee.
>>>>> 
>>>>> Any views?  You all have edit rights.
>>>>> 
>>>>> I think that the draft covers Moritz's and Julian's goals, at least that was my intention.  I have pasted Moritz's last email below, for context.
>>>>> 
>>>>> Simon
>>>>> 
>>>>> 
>>>>> ========= Moritz's last email ============
>>>>> 
>>>>> Now, this is derailing the original discussion a bit, and I'm not sure how far we want to take this. But, regarding @Simon Marlow <mailto:marlowsd at gmail.com>'s comment
>>>>> 
>>>>>> This is one cultural aspect of our community I'd like to shift: the
>>>>>> expectation that it's OK to make breaking changes as long as you warn about
>>>>>> them or go through a migration cycle. It just isn't! (and I speak as
>>>>>> someone who used to make lots of changes, I'm now fully repentant!). That's
>>>>>> not to say that we shouldn't ever change anything, but when considering the
>>>>>> cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it
>>>>>> just defers it.
>>>>> 
>>>>> I actually read this as we should stop having breaking changes to begin with. And _if_ we
>>>>> do have breaking changes, that deprecation does not change the need to actually change
>>>>> code (cost). As outlined in my reply to that, and @Richard Eisenberg <mailto:lists at richarde.dev>'s observation, it 
>>>>> "smears" the cost. The--to me--_much_ bigger implication of deprecation cycles is that we
>>>>> _inform_ our _customers_ about upcoming changes _early_, instead of _after the fact_. We
>>>>> also give them ample time to react. Being by changing their code, or raising their concerns.
>>>>> Would the Simplified Subsumptions / Deep Subsumptions change have looked differently?
>>>>> As such I see deprecation cycles as orthogonal to the question if we should have breaking
>>>>> changes to begin with.
>>>>> 
>>>>> Thus I believe the following:
>>>>>> - Do have a deprecation cycle if possible.
>>>>>> - Do not treat a deprecation cycle as an excuse.  Costs are deferred but are as large as ever.
>>>>> 
>>>>> should be upgraded to:
>>>>> - Preferably _no_ breaking changes.
>>>>> - If breaking changes, then with a deprecation cycle, unless technically infeasible.
>>>>> - An understanding that any breaking change incurs significant costs.
>>>>> 
>>>>> Ocaml recently added multicore support, and they put tremendous effort into making
>>>>> sure it keeps backwards compatibility: https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>>> 
>>>>>> PS: we should also agree that a "stable" extension should not require dependencies on ghc-experimental.  To become stable, any library support for an extension must move into `base`.
>>>>> 
>>>>> This seems like a good idea, however I still remain that _experimental_ features should not be on-by-default in a stable compiler. Yes, ideally I'd not even see them in a stable compiler, but I know this view is contentious. The use of `ghc-experimental` should therefore be guarded by `--std=experimental` as Julian suggested. That is a loud opt-in to experimental features.
>>>>> _______________________________________________
>>>>> 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/20230923/0eca6ad7/attachment.html>

From eric at seidel.io  Sun Sep 24 13:36:16 2023
From: eric at seidel.io (Eric Seidel)
Date: Sun, 24 Sep 2023 09:36:16 -0400
Subject: [ghc-steering-committee] #583: HasField redesign, rec: accept
In-Reply-To: <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
References: <CAGwnsn=sMx6_Z2hZk4wrxs8Ry0p4kTTQYKiX+kpFXe+T2rVbfQ@mail.gmail.com>
 <CAJKmMz_dHKn81RdL=4WiVtHy=sA-4=E8_Ljykx+GeOOdyyMK7A@mail.gmail.com>
 <CAGwnsnk+0E7CD2LGC4g+mN=J+7XFnRKzjWBTAudNszg6_RJC6A@mail.gmail.com>
 <CAGwnsn=q7VCqL=d49Hg38Q086qTyhvsTEnrrhjxsyKL1qFe9Zg@mail.gmail.com>
Message-ID: <e98596f2-6d99-4d82-aa8e-4059c64d5540@app.fastmail.com>

I am in favor of this proposal.

On Thu, Sep 21, 2023, at 03:37, Arnaud Spiwack wrote:
> Dear all.
>
> I submitted my recommendation 3 weeks ago, and only Simon has commented 
> yet. Please let me know your thoughts.
>
> On Wed, 6 Sept 2023 at 16:27, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>> Dear all,
>> 
>> Don't forget to opine here. To reiterate, I really don't expect the proposal to be controversial. The text of the proposal is rather long, but is made easy to read. So it shouldn't take too much of your time.
>> 
>> /Arnaud
>> 
>> On Thu, 31 Aug 2023 at 01:03, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>>> I support acceptance.
>>> 
>>> Simon
>>> 
>>> On Wed, 30 Aug 2023 at 16:09, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
>>>> Dear all,
>>>> 
>>>> [ Proposal #583 https://github.com/ghc-proposals/ghc-proposals/pull/583 ]
>>>> 
>>>> Our own Adam proposes to amend the design of the highly experimental OverloadedRecordUpdate extension as had been designed in proposal #158 [ https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0158-record-set-field.rst ] and #405 [ https://github.com/ghc-proposals/ghc-proposals/pull/405 ].
>>>> 
>>>> Specifically, Adam proposes a modification of the type classes that would back the extension.
>>>> 
>>>> In the previous design the HasField class is defined as a lens:
>>>> 
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> (a -> r, a)
>>>> 
>>>> The proposal is to replace it by two classes (slightly simplified)
>>>> 
>>>> class HasField (n :: k) r a | r n -> a
>>>>   hasField :: r -> a
>>>> 
>>>> class SetField (n::k) r a | r n -> a
>>>>   modifyField :: (a -> a) -> r -> a
>>>>   setField :: a -> r -> a
>>>> 
>>>> This is originally motivated by some performance consideration: the prototype implementation of HasField as a lens can be very time consuming because instances of HasFields are generated eagerly at record definition sites, whereas the simple HasField instances can simply reuse the selectors already generated by GHC. But a lot of thoughts have been put into the new design, and my summary can certainly not do it justice: the proposal is very well argumented.
>>>> 
>>>> A point I'll make here is that the new design is actually parametric in the data representation of the field type. Something that wasn't possible in the original design.
>>>> 
>>>> This proposal is not technically backward compatible, because the order of argument in which OverloadedRecordUpdate expects the argument of setField is changed. This is not essential to the proposal, but this is a more consistent order argument with the rest of Haskell. And considering that OverloadedRecordUpdate is very loudly advertised as experimental, I recommend accepting this breakage.
>>>> 
>>>> Overall the proposal is actually more backward compatible with GHC 9.8 than the original design, as the HasField class is left unchanged.
>>>> 
>>>> Overall, the proposal looks quite reasonable to me, and well-argued. I recommend acceptance.
>>>> 
>>>> -- 
>>>> Arnaud Spiwack
>>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> 
>> -- 
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>
>
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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  Sun Sep 24 13:56:59 2023
From: eric at seidel.io (Eric Seidel)
Date: Sun, 24 Sep 2023 09:56:59 -0400
Subject: [ghc-steering-committee] #571: -Wsevere,
	Shepherd: Adam (rec: accept)
In-Reply-To: <AFC83507-E642-40A1-A703-15C34B8AD0BA@chrisdornan.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
 <CAJKmMz-Ttpa+EnNe5A+vS6qgf6u32LPnggv0DTnoQ8sep9mH6Q@mail.gmail.com>
 <CAGwnsnmXnspOzpjYGTysUA1zP7d70KjuV_8wavpqsY=9YD3gXg@mail.gmail.com>
 <010f018aa9c3dc08-37e029e1-be49-4956-b9ce-c063c025988e-000000@us-east-2.amazonses.com>
 <c84e4431-3bee-8692-2e42-1cfa7dac62c1@well-typed.com>
 <CAKfdd-zKc+hf=P+bh4Z_O+g9u-j-F1uY3ea=PuMMfCarmXwCPg@mail.gmail.com>
 <CANsrgPJLnREjW8bSRutZ=Nf2XRejwY8zHWULdLVVXcVHeaYvCg@mail.gmail.com>
 <0814582A-F9B5-4A81-95AE-821F235B68D6@chrisdornan.com>
 <CAJKmMz9Qb0kK2Ywxoq=EoROva2ufGWub4xf7RwrTvtEb4bPHkw@mail.gmail.com>
 <b006d575915cf8092602d1dcf3a5a1574f640a5b.camel@joachim-breitner.de>
 <52c46b13-9525-68c9-a9b7-31a97a6a6a11@well-typed.com>
 <CANsrgP+Kn_BW_J_AgKfbmYACnKuzJ1Rruv9fr=DBf5oQq-pZ7w@mail.gmail.com>
 <CAKfdd-wW=CiGA91Hzd4n6GRRMEWQnXUkQ2AZNt81Co5mgeZXDw@mail.gmail.com>
 <AFC83507-E642-40A1-A703-15C34B8AD0BA@chrisdornan.com>
Message-ID: <5dba93e2-c89a-4fa1-a3a9-7cd40bfcfadc@app.fastmail.com>

I agree with Chris and Simon M. I would probably support turning these warnings into errors as part of the next GHC20XX standard, but not as an isolated one-off change.

On Fri, Sep 22, 2023, at 07:16, Chris Dornan wrote:
> Moritz, can I pass on some excellent advice I got from Richard on first 
> joining the list, namely don't try to 'read the room' here but call 
> things as you see them. Thanks to some excellent management from the 
> usual suspects we are quite good at searching out a consensus when 
> needed.
>
> I am strongly in agreement with Simon Marlow here -- I really don't 
> think we should be introducing breaking changes unless it is really, 
> really necessary, and I just don't think "this is what we think 
> developers should be doing" and "nobody reads manuals any more" clears 
> the threshold for me. And, while I take Richard's point about the value 
> of deprecation periods, I still think we should only introduce breaking 
> changes in exceptional circumstances.
>
> Again, I fully support the introduction of the Severe category with the 
> proposed warnings included. 
>
> The way I would approach this is to predicate the change of behaviour 
> on a language extension with a view to getting it included in (say) 
> GHC2024. People that really care about stability can tie things down by 
> specifying the language they are working with at the appropriate 
> points. Folks are now used to the GHC selecting a new default once a 
> new Haskell* or GHC* standard is agreed.
>
> Chris
> 
>
>> On 21 Sep 2023, at 14:13, Moritz Angermann <moritz.angermann at gmail.com> wrote:
>> 
>> Thank you Simon! 
>> 
>> I think this raises a good point, in that _any_ breaking change should stand well on its own wrt to a cost/benefit analysis.
>> 
>> I’m not sure if we disagree or not.  I’ve assumed that the majority wants to make these changes.  I also often do not feel sufficiently capable enough to make a convincing argument against a specific change. 
>> 
>> Thus under the assumption that we are going to make a breaking change (because the majority want this), I feel very strongly about informing end users beforehand as well as the quality control aspect of being able to run regression tests by just swapping out the compiler trivially.
>> 
>> Thus *if* we are making a breaking change, I do not believe that a migration phase reduces the costs much (you still need to adjust your code), but I consider a breaking change without migration phase to be significantly worse to a breaking change with migration phase.
>> 
>> The difference for me practically lies in the following:
>> If we migrate to a new compiler, a team of engineers start doing the initial migration for us (this means adding the new compiler to CI, and making sure existing code at least builds), this happens for multiple projects/components in dependency order.
>> 
>> After this has happened the project/component teams use the new compiler and fix their code.
>> 
>> If we have migration warnings for upcoming breaking changes, the work shifts from the new-compiler-across-multiple-projects team into the project teams.
>> 
>> This makes the whole add new compiler process significantly faster, and means less friction. It also means the project teams who have much better knowledge of their specific project can address the warnings better than the migration team which has to dig deep into existing code bases, get familiar with the code to make the necessity adjustments (or request pair sessions that take time from other tasks).
>> 
>> It also gives one more opportunity for the community to raise their hand and say, oh hell no, that’s a stupid idea; I’m going to complain about this! (I’ve been told this more than once; migration phases could also be seen as community inquiery, to get feedback from actual practitioners).
>> 
>> After writing this all down, I guess my push for “if breaking change, then only with migration phase” is orthogonal to “should we have breaking changes to begin with?”
>> 
>> Cheers,
>>   Moritz
>> 
>> On Thu, 21 Sep 2023 at 8:35 PM, Simon Marlow <marlowsd at gmail.com> wrote:
>>> I might be an outlier here, but deferring the change to a later release and adding an intermediate warning doesn't make it any less bad.
>>> 
>>> This is one cultural aspect of our community I'd like to shift: the expectation that it's OK to make breaking changes as long as you warn about them or go through a migration cycle. It just isn't! (and I speak as someone who used to make lots of changes, I'm now fully repentant!). That's not to say that we shouldn't ever change anything, but when considering the cost/benefit tradeoff adding a migration cycle doesn't reduce the cost, it just defers it.
>>> 
>>> Cheers
>>> Simon
>>> 
>>> 
>>> 
>>> On Wed, 20 Sept 2023 at 08:25, Adam Gundry <adam at well-typed.com> wrote:
>>>> I agree with Joachim's position here.
>>>> 
>>>> Having a -Wsevere group at all would be a good start, but the problem 
>>>> with stopping at "best-practice guidance" rather than changing the 
>>>> defaults is that it benefits only those who learn about and follow the 
>>>> guidance. So it remains a footgun for newcomers.
>>>> 
>>>> Regarding migration, given that GHC has issued these warnings by default 
>>>> for some time, I don't think we need be too shy about upgrading their 
>>>> severity. We could have -Wcompat imply -Werror=severe, but that 
>>>> complicates the semantics of warning groups, and will help only those 
>>>> who use -Wcompat but don't fix warnings that occur with -Wdefault.
>>>> 
>>>> I suppose as Moritz suggests we could introduce and advertise -Wsevere 
>>>> in 9.10, and mention in the warning message that this will be an error 
>>>> in the future, but only enable -Werror=severe in 9.14 (or 9.12?), so 
>>>> 9.10 would give something like:
>>>> 
>>>> M.hs:8:10: warning: [-Wmissing-methods]
>>>>      • No explicit implementation for
>>>>          ‘<>’
>>>>      • In the instance declaration for ‘Semigroup T’
>>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>>      • This will become an error by default in a future GHC release;
>>>>        use -Werror=severe to make severe warnings into errors now.
>>>> 
>>>> Then in a future release:
>>>> 
>>>> M.hs:8:10: error: [-Wmissing-methods, -Werror=missing-methods]
>>>>      • No explicit implementation for
>>>>          ‘<>’
>>>>      • In the instance declaration for ‘Semigroup T’
>>>>      • Warning: this may lead to an infinite loop or runtime exception.
>>>>      • Use -Wwarn=missing-methods to permit this anyway.
>>>> 
>>>> Would that be a reasonable compromise?
>>>> 
>>>> Adam
>>>> 
>>>> 
>>>> On 19/09/2023 22:13, Joachim Breitner wrote:
>>>> > Hi,
>>>> > 
>>>> > Am Dienstag, dem 19.09.2023 um 15:26 +0100 schrieb Simon Peyton Jones:
>>>> >> Maybe implementing this "severe" category, but not changing its
>>>> >> default to error, would get us some of the way there?  Then "best-
>>>> >> practice guidance" could be "use -Werror=severe", and job done.
>>>> >> That's a bit easier to say than saying "use -Werrror=missing-methods
>>>> >> -Werror= ..." etc.
>>>> > 
>>>> > anyone using `-Werror` would already get this behavior. So what is the
>>>> > useful for using `-Werror=severe` instead? Presumably the rationale is:
>>>> > 
>>>> >   -Werror, while great _during_ development or in leaf packages, is not
>>>> >   is not good idea in _released_ code, i.e. code that is compiled by
>>>> >   others, as that code needs to keep working even as compilers and
>>>> >   dependencies change, such as libraries on hackage, or executables
>>>> >   built by distro packagers.
>>>> >   That’s why -Werror is frowned upon there.
>>>> > 
>>>> >   But some changes in upstream packages _ought_ to cause compilation to
>>>> >   fail, because they really need downstream code changes. These will
>>>> >   cause severe warnings, and therefore -Werror=severe is desirable
>>>> >   even for released code.
>>>> > 
>>>> > Is that a good way of phrasing your thoughts there?
>>>> > 
>>>> > It looks reasonable to me; if we think of deferable type error as
>>>> > severe warnings, it totally fits this description: It would be
>>>> > _possible_ to keep compiling the downstream code, but it would not be
>>>> > desirable. That's why compilation fails, and that’s why we don’t defer
>>>> > type errors by default.
>>>> > 
>>>> > But if -Werror=severe is desirable generally, it would be unfortunate
>>>> > if we cannot make it the default. If not right away, then maybe with a
>>>> > suitable migration strategy? (Although I wonder if there are many users
>>>> > out there that pay attention to deprecation warnings, e.g. watch
>>>> > -Wdeprecation, that would not have already fixed -Wdefault warnings
>>>> > about missing fields/methods already…)
>>>> > 
>>>> > 
>>>> > Cheers,
>>>> > Joachim
>>>> 
>>>> -- 
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>> 
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> 
>>>> _______________________________________________
>>>> 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  Sun Sep 24 15:51:20 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 24 Sep 2023 17:51:20 +0200
Subject: [ghc-steering-committee] Please review #569: multiline string
 literals, Shepherd: Eric
Message-ID: <a014e8f0d68ec103abb248a6ddf335006df1f9ca.camel@joachim-breitner.de>

Dear Committee,

Brandon Chinn has a proposal for multiline string literals.
Let the bikeshedding begin.

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

https://github.com/brandonchinn178/ghc-proposals/blob/multiline-strings/proposals/0569-multiline-strings.rst

I’d like to nominate Eric as the shepherd.

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


Cheers,
Joachim




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


From adam at well-typed.com  Mon Sep 25 07:16:53 2023
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 25 Sep 2023 08:16:53 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
Message-ID: <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>

I'm afraid that I'm somewhat sceptical of this approach.

A strong stability guarantee is certainly a valuable goal, but it also 
comes with costs, which I'd like to see more clearly articulated. Some 
of them include:

  * Cognitive overhead for users, because of the inability to remove 
complexity from the design.

  * Increasing maintenance burden in the compiler, because of the 
additional work needed to implement new features and the inability to 
remove complexity from the implementation.

  * A risk of getting stuck in a local optimum, because moving to a 
better design would entail breaking changes.

  * Discouraging volunteer contributors, who are much less likely to 
work on a potentially beneficial change if the process for getting it 
approved is too onerous. (I'm worried we're already reaching that point 
due to the increasing burden of well-intentioned processes.)

Ultimately every proposed change has a cost-benefit trade-off, with risk 
of breakage being one of the costs. We need to consciously evaluate that 
trade-off on a case-by-case basis. Almost all changes might break 
something (e.g. by regressing performance, or for Hyrum's Law reasons), 
so there needs to be a proportionate assessment of how likely each 
change is to be damaging in practice, bearing in mind that such an 
assessment is itself costly and limited in scope.

It seems to me that the GHC team have taken on board lessons regarding 
stability of the language, and the extension system already gives quite 
a lot of flexibility to evolve the language in a backwards-compatible 
way. In my experience, the key stability problems preventing upgrades to 
recent GHC releases are:

  * The cascading effect of breaking changes in one library causing the 
need to upgrade libraries which depend upon it. This is primarily under 
the control of the CLC and library maintainers, however, not the GHC 
team. It would help if base was minimal and reinstallable, but that 
isn't a total solution either, because you'd still have to worry about 
packages depending on template-haskell or the ghc package itself.

  * Performance regressions or critical bugs. These tend to be a 
significant obstacle to upgrading for smaller commercial users. But 
spending more of our limited resources on stability of the language 
means fewer resources for resolving these issues.

There's surely more we can do here, but let's be careful not to pay too 
many costs to achieve stability of the *language* alone, when stability 
of the *libraries* and *implementation* are both more important and 
harder to fix.

Adam


On 22/09/2023 10:53, Simon Peyton Jones wrote:
> Dear GHC SC
> 
> To avoid derailing the debate about -Wsevere 
> <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
> 
> I have tried to articulate what I believe is an evolving consensus in 
> this document 
> <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
> 
> If we converge, we'll turn that into a proper PR for the GHC proposal 
> process, although it has wider implications than just GHC proposals and 
> we should share with a broader audience.  But let's start with the 
> steering committee.
> 
> Any views?  You all have edit rights.
> 
> I think that the draft covers Moritz's and Julian's goals, at least that 
> was my intention.  I have pasted Moritz's last email below, for context.
> 
> Simon
> 
> 
> ========= Moritz's last email ============
> 
> Now, this is derailing the original discussion a bit, and I'm not sure 
> how far we want to take this. But, regarding @Simon Marlow 
> <mailto:marlowsd at gmail.com>'s comment
> 
>     This is one cultural aspect of our community I'd like to shift: the
>     expectation that it's OK to make breaking changes as long as you
>     warn about
>     them or go through a migration cycle. It just isn't! (and I speak as
>     someone who used to make lots of changes, I'm now fully repentant!).
>     That's
>     not to say that we shouldn't ever change anything, but when
>     considering the
>     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>     cost, it
>     just defers it.
> 
> 
> I actually read this as we should stop having breaking changes to begin 
> with. And _if_ we
> do have breaking changes, that deprecation does not change the need to 
> actually change
> code (cost). As outlined in my reply to that, and @Richard Eisenberg 
> <mailto:lists at richarde.dev>'s observation, it
> "smears" the cost. The--to me--_much_ bigger implication of deprecation 
> cycles is that we
> _inform_ our _customers_ about upcoming changes _early_, instead of 
> _after the fact_. We
> also give them ample time to react. Being by changing their code, or 
> raising their concerns.
> Would the Simplified Subsumptions / Deep Subsumptions change have looked 
> differently?
> As such I see deprecation cycles as orthogonal to the question if we 
> should have breaking
> changes to begin with.
> 
> Thus I believe the following:
> 
>     - Do have a deprecation cycle if possible.
>     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>     but are as large as ever.
> 
> 
> should be upgraded to:
> - Preferably _no_ breaking changes.
> - If breaking changes, then with a deprecation cycle, unless technically 
> infeasible.
> - An understanding that any breaking change incurs significant costs.
> 
> Ocaml recently added multicore support, and they put tremendous effort 
> into making
> sure it keeps backwards compatibility: 
> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md 
> <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
> 
>     PS: we should also agree that a "stable" extension should not
>     require dependencies on ghc-experimental.  To become stable, any
>     library support for an extension must move into `base`.
> 
> 
> This seems like a good idea, however I still remain that _experimental_ 
> features should not be on-by-default in a stable compiler. Yes, ideally 
> I'd not even see them in a stable compiler, but I know this view is 
> contentious. The use of `ghc-experimental` should therefore be guarded 
> by `--std=experimental` as Julian suggested. That is a loud opt-in to 
> experimental features.
> 

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From simon.peytonjones at gmail.com  Mon Sep 25 08:46:44 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 25 Sep 2023 09:46:44 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
Message-ID: <CAJKmMz_FHkzvxRYLzZcE0sODN8YNf-6VxE1DtMeS6PEtJC=hJA@mail.gmail.com>

>
> A strong stability guarantee is certainly a valuable goal, but it also
> comes with costs, which I'd like to see more clearly articulated. Some
> of them include:
>

Thanks for articulating this.

I see this doc as the language counterpart of the base-libraries document,
where we split `base` and `ghc-experimental`.  By splitting in this way, we
allow innovation, while placing stronger stability goals on `base`.
Stronger,  but not unbreakable: I expect base to continue to evolve, e.g.
by removing (with deprecation cycles) stuff that is plainly GHC-internal,
subject to the CLC.  But, as we have seen in the extensive debate that led
up to this proposal, it is *really *helpful to have a clear line between
"experimental" and "stable", for all sorts of reasons.

I think we are just doing the same here.  Many GHC proposals add a new
language feature, guarded by an extension, and are unaffected by the
proposal.  Others make changes to recently added extensions (Linear Haskell
is the poster child example), which we informally regard as experimental
and subject to change. But we don't *say* that at the moment... it's all
informal.  By identifying which extensions are experimental, and which are
stable (and subject to higher back-compat goals) we help our users, and
ourselves.  Just like base vs ghc-experimental.

I called them "General Rules" because (just like changes to base) I think
we will want to break them.  But I'm content to be considerably more
careful when we break stable extensions than experimental ones.

=============

Template Haskell is a real problem.  I don't think we can promise never to
change TH syntax, for the reasons you describe.

Is it true that many TH users use only splices and quotations, not explicit
use of TH data constructors?  Those programs should be much more stable.

For ones that use TH data constructors I think that prompt (but very
routine) maintenance may be needed.

Simon




On Mon, 25 Sept 2023 at 08:17, Adam Gundry <adam at well-typed.com> wrote:

> I'm afraid that I'm somewhat sceptical of this approach.
>
> A strong stability guarantee is certainly a valuable goal, but it also
> comes with costs, which I'd like to see more clearly articulated. Some
> of them include:
>
>   * Cognitive overhead for users, because of the inability to remove
> complexity from the design.
>
>   * Increasing maintenance burden in the compiler, because of the
> additional work needed to implement new features and the inability to
> remove complexity from the implementation.
>
>   * A risk of getting stuck in a local optimum, because moving to a
> better design would entail breaking changes.
>
>   * Discouraging volunteer contributors, who are much less likely to
> work on a potentially beneficial change if the process for getting it
> approved is too onerous. (I'm worried we're already reaching that point
> due to the increasing burden of well-intentioned processes.)
>
> Ultimately every proposed change has a cost-benefit trade-off, with risk
> of breakage being one of the costs. We need to consciously evaluate that
> trade-off on a case-by-case basis. Almost all changes might break
> something (e.g. by regressing performance, or for Hyrum's Law reasons),
> so there needs to be a proportionate assessment of how likely each
> change is to be damaging in practice, bearing in mind that such an
> assessment is itself costly and limited in scope.
>
> It seems to me that the GHC team have taken on board lessons regarding
> stability of the language, and the extension system already gives quite
> a lot of flexibility to evolve the language in a backwards-compatible
> way. In my experience, the key stability problems preventing upgrades to
> recent GHC releases are:
>
>   * The cascading effect of breaking changes in one library causing the
> need to upgrade libraries which depend upon it. This is primarily under
> the control of the CLC and library maintainers, however, not the GHC
> team. It would help if base was minimal and reinstallable, but that
> isn't a total solution either, because you'd still have to worry about
> packages depending on template-haskell or the ghc package itself.
>
>   * Performance regressions or critical bugs. These tend to be a
> significant obstacle to upgrading for smaller commercial users. But
> spending more of our limited resources on stability of the language
> means fewer resources for resolving these issues.
>
> There's surely more we can do here, but let's be careful not to pay too
> many costs to achieve stability of the *language* alone, when stability
> of the *libraries* and *implementation* are both more important and
> harder to fix.
>
> Adam
>
>
> On 22/09/2023 10:53, Simon Peyton Jones wrote:
> > Dear GHC SC
> >
> > To avoid derailing the debate about -Wsevere
> > <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
> and HasField redesign <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
> I'm starting a new (email for now) thread about stability.
> >
> > I have tried to articulate what I believe is an evolving consensus in
> > this document
> > <
> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
> >.
> >
> > If we converge, we'll turn that into a proper PR for the GHC proposal
> > process, although it has wider implications than just GHC proposals and
> > we should share with a broader audience.  But let's start with the
> > steering committee.
> >
> > Any views?  You all have edit rights.
> >
> > I think that the draft covers Moritz's and Julian's goals, at least that
> > was my intention.  I have pasted Moritz's last email below, for context.
> >
> > Simon
> >
> >
> > ========= Moritz's last email ============
> >
> > Now, this is derailing the original discussion a bit, and I'm not sure
> > how far we want to take this. But, regarding @Simon Marlow
> > <mailto:marlowsd at gmail.com>'s comment
> >
> >     This is one cultural aspect of our community I'd like to shift: the
> >     expectation that it's OK to make breaking changes as long as you
> >     warn about
> >     them or go through a migration cycle. It just isn't! (and I speak as
> >     someone who used to make lots of changes, I'm now fully repentant!).
> >     That's
> >     not to say that we shouldn't ever change anything, but when
> >     considering the
> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
> >     cost, it
> >     just defers it.
> >
> >
> > I actually read this as we should stop having breaking changes to begin
> > with. And _if_ we
> > do have breaking changes, that deprecation does not change the need to
> > actually change
> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
> > <mailto:lists at richarde.dev>'s observation, it
> > "smears" the cost. The--to me--_much_ bigger implication of deprecation
> > cycles is that we
> > _inform_ our _customers_ about upcoming changes _early_, instead of
> > _after the fact_. We
> > also give them ample time to react. Being by changing their code, or
> > raising their concerns.
> > Would the Simplified Subsumptions / Deep Subsumptions change have looked
> > differently?
> > As such I see deprecation cycles as orthogonal to the question if we
> > should have breaking
> > changes to begin with.
> >
> > Thus I believe the following:
> >
> >     - Do have a deprecation cycle if possible.
> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
> >     but are as large as ever.
> >
> >
> > should be upgraded to:
> > - Preferably _no_ breaking changes.
> > - If breaking changes, then with a deprecation cycle, unless technically
> > infeasible.
> > - An understanding that any breaking change incurs significant costs.
> >
> > Ocaml recently added multicore support, and they put tremendous effort
> > into making
> > sure it keeps backwards compatibility:
> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
> >
> >     PS: we should also agree that a "stable" extension should not
> >     require dependencies on ghc-experimental.  To become stable, any
> >     library support for an extension must move into `base`.
> >
> >
> > This seems like a good idea, however I still remain that _experimental_
> > features should not be on-by-default in a stable compiler. Yes, ideally
> > I'd not even see them in a stable compiler, but I know this view is
> > contentious. The use of `ghc-experimental` should therefore be guarded
> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
> > experimental features.
> >
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230925/25f85b98/attachment.html>

From simon.peytonjones at gmail.com  Mon Sep 25 09:03:08 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 25 Sep 2023 10:03:08 +0100
Subject: [ghc-steering-committee] Warnings
Message-ID: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>

Dear GHC SC

You may or may not have been following GHC ticket #22141
<https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge
request !11314 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>.

The story is this:

   - There is a bug in GHC that allows programs to use DataKinds without
   the -XDataKinds extension.
   - The MR fixes the bug.
   - But of course that will mean that some programs that previously
   compiled (exploiting the bug) will now fail to compile (correctly).

It seems like an example of our (GR2) discussion, but with a very different
flavour than the  (3+4=8) example.

Personally I think we should do it -- with a deprecation cycle saying "You
need DataKinds for this program, and you don't have it on, but you will
need it in the next release".   I don't want us to grandfather bugs into
GHC indefinitely -- although you could argue that the status quo does
little harm, I suppose.

Any views?   We will have some idea of the impact on head.hackage shortly.

*And specifically: do you want a GHC proposal for this change?*

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230925/191fcc67/attachment-0001.html>

From moritz.angermann at gmail.com  Mon Sep 25 09:25:10 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 25 Sep 2023 17:25:10 +0800
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
Message-ID: <CAKfdd-xVBzsDCJU5q+9nMiXXzNE_BLX9C8G+D3+0+BGhcJD2dQ@mail.gmail.com>

Hi Simon,

I'm strongly in favour of the deprecation cycle (can we even backport the
warning to patch releases?).
I'm not sure we need a GHC proposal for this? Would this mean we need a
proposal for every bug fix
down the line?

My view is as follows: I do not believe anyone exploits this bug _on
purpose_. And breaking their code
suddenly because, they overlooked a necessity no one informed them about,
seems hostile to users,
warning them and letting them know that this lack of declaration will be
rejected in the future seems the
right approach to me. If we can warn them even earlier (with older patch
releases, the better).

Cheers,
 Moritz

On Mon, 25 Sept 2023 at 17:03, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Dear GHC SC
>
> You may or may not have been following GHC ticket #22141
> <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge
> request !11314 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>
> .
>
> The story is this:
>
>    - There is a bug in GHC that allows programs to use DataKinds without
>    the -XDataKinds extension.
>    - The MR fixes the bug.
>    - But of course that will mean that some programs that previously
>    compiled (exploiting the bug) will now fail to compile (correctly).
>
> It seems like an example of our (GR2) discussion, but with a very
> different flavour than the  (3+4=8) example.
>
> Personally I think we should do it -- with a deprecation cycle saying "You
> need DataKinds for this program, and you don't have it on, but you will
> need it in the next release".   I don't want us to grandfather bugs into
> GHC indefinitely -- although you could argue that the status quo does
> little harm, I suppose.
>
> Any views?   We will have some idea of the impact on head.hackage shortly.
>
> *And specifically: do you want a GHC proposal for this change?*
>
> Simon
> _______________________________________________
> 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/20230925/b81cd1b1/attachment.html>

From eric at seidel.io  Mon Sep 25 11:48:52 2023
From: eric at seidel.io (Eric Seidel)
Date: Mon, 25 Sep 2023 07:48:52 -0400
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
Message-ID: <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>

I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix. 

I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)

On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:
> Dear GHC SC
>
> You may or may not have been following GHC ticket #22141 
> <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge 
> request !11314 
> <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>.
>
> The story is this:
>  • There is a bug in GHC that allows programs to use DataKinds without 
> the -XDataKinds extension.
>  • The MR fixes the bug.
>  • But of course that will mean that some programs that previously 
> compiled (exploiting the bug) will now fail to compile (correctly).
> It seems like an example of our (GR2) discussion, but with a very 
> different flavour than the  (3+4=8) example.
>
> Personally I think we should do it -- with a deprecation cycle saying 
> "You need DataKinds for this program, and you don't have it on, but you 
> will need it in the next release".   I don't want us to grandfather 
> bugs into GHC indefinitely -- although you could argue that the status 
> quo does little harm, I suppose.
>
> Any views?   We will have some idea of the impact on head.hackage shortly.
>
> *And specifically: do you want a GHC proposal for this change?*
>
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From marlowsd at gmail.com  Mon Sep 25 12:41:07 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Mon, 25 Sep 2023 13:41:07 +0100
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
 <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
Message-ID: <CANsrgPKZ7VtfiWo10A5V8kKK9+QBAuZ191awBqYpCT9usuNprw@mail.gmail.com>

+1 - fix the bug with a warning cycle.

Maybe a good rule of thumb for when GR2 applies is: does the current
behaviour contradict the documentation? (probably not applicable in all
cases, of course)

Cheers
Simon

On Mon, 25 Sept 2023 at 12:49, Eric Seidel <eric at seidel.io> wrote:

> I agree with Moritz that a GHC Proposal is not necessary. Proposals should
> be used for changes in *intended* user-facing behavior, this is just a
> routine bugfix.
>
> I also agree that a warning/deprecation period would be good, but I
> wouldn't spend overly on it. This sounds like a very easy issue to work
> around, just enable the extension explicitly. (Or would that have potential
> second-order consequences?)
>
> On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:
> > Dear GHC SC
> >
> > You may or may not have been following GHC ticket #22141
> > <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge
> > request !11314
> > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>.
> >
> > The story is this:
> >  • There is a bug in GHC that allows programs to use DataKinds without
> > the -XDataKinds extension.
> >  • The MR fixes the bug.
> >  • But of course that will mean that some programs that previously
> > compiled (exploiting the bug) will now fail to compile (correctly).
> > It seems like an example of our (GR2) discussion, but with a very
> > different flavour than the  (3+4=8) example.
> >
> > Personally I think we should do it -- with a deprecation cycle saying
> > "You need DataKinds for this program, and you don't have it on, but you
> > will need it in the next release".   I don't want us to grandfather
> > bugs into GHC indefinitely -- although you could argue that the status
> > quo does little harm, I suppose.
> >
> > Any views?   We will have some idea of the impact on head.hackage
> shortly.
> >
> > *And specifically: do you want a GHC proposal for this change?*
> >
> > Simon
> > _______________________________________________
> > 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/20230925/27514107/attachment.html>

From moritz.angermann at gmail.com  Mon Sep 25 12:43:27 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 25 Sep 2023 20:43:27 +0800
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
 <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
Message-ID: <CAKfdd-ymU=DkNOiYSLPomkw8ig=jS8=Lm0heviRs5PnAVmrOQQ@mail.gmail.com>

I actually think a warning/deprecation period should be down in this case.
It doesn’t break code right now. It is not critical for this to be fixed
immediately (nothing significantly averse will happen to someone
accidentally using this).

I’m willing to put some of IOGs resources at helping with implementing the
deprecation warnings; leading by example, hoping this will inspire others
to do the same in the future.

Best,
 Moritz

On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel <eric at seidel.io> wrote:

> I agree with Moritz that a GHC Proposal is not necessary. Proposals should
> be used for changes in *intended* user-facing behavior, this is just a
> routine bugfix.
>
> I also agree that a warning/deprecation period would be good, but I
> wouldn't spend overly on it. This sounds like a very easy issue to work
> around, just enable the extension explicitly. (Or would that have potential
> second-order consequences?)
>
> On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:
> > Dear GHC SC
> >
> > You may or may not have been following GHC ticket #22141
> > <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge
> > request !11314
> > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>.
> >
> > The story is this:
> >  • There is a bug in GHC that allows programs to use DataKinds without
> > the -XDataKinds extension.
> >  • The MR fixes the bug.
> >  • But of course that will mean that some programs that previously
> > compiled (exploiting the bug) will now fail to compile (correctly).
> > It seems like an example of our (GR2) discussion, but with a very
> > different flavour than the  (3+4=8) example.
> >
> > Personally I think we should do it -- with a deprecation cycle saying
> > "You need DataKinds for this program, and you don't have it on, but you
> > will need it in the next release".   I don't want us to grandfather
> > bugs into GHC indefinitely -- although you could argue that the status
> > quo does little harm, I suppose.
> >
> > Any views?   We will have some idea of the impact on head.hackage
> shortly.
> >
> > *And specifically: do you want a GHC proposal for this change?*
> >
> > Simon
> > _______________________________________________
> > 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/20230925/2aead8c3/attachment.html>

From lists at richarde.dev  Mon Sep 25 13:30:13 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 25 Sep 2023 13:30:13 +0000
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <CAKfdd-ymU=DkNOiYSLPomkw8ig=jS8=Lm0heviRs5PnAVmrOQQ@mail.gmail.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
 <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
 <CAKfdd-ymU=DkNOiYSLPomkw8ig=jS8=Lm0heviRs5PnAVmrOQQ@mail.gmail.com>
Message-ID: <010f018acc888394-7093842b-42eb-4270-9359-8044154865f3-000000@us-east-2.amazonses.com>

Yes, let's fix the bug with a deprecation cycle.

> On Sep 25, 2023, at 8:43 AM, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> I actually think a warning/deprecation period should be down in this case. It doesn’t break code right now. It is not critical for this to be fixed immediately (nothing significantly averse will happen to someone accidentally using this).
> 
> I’m willing to put some of IOGs resources at helping with implementing the deprecation warnings; leading by example, hoping this will inspire others to do the same in the future. 
> 
> Best,
>  Moritz
> 
> On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix. 
> 
> I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)
> 
> On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:
> > Dear GHC SC
> >
> > You may or may not have been following GHC ticket #22141 
> > <https://gitlab.haskell.org/ghc/ghc/-/issues/22141 <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>>, and Ryan's merge 
> > request !11314 
> > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>>.
> >
> > The story is this:
> >  • There is a bug in GHC that allows programs to use DataKinds without 
> > the -XDataKinds extension.
> >  • The MR fixes the bug.
> >  • But of course that will mean that some programs that previously 
> > compiled (exploiting the bug) will now fail to compile (correctly).
> > It seems like an example of our (GR2) discussion, but with a very 
> > different flavour than the  (3+4=8) example.
> >
> > Personally I think we should do it -- with a deprecation cycle saying 
> > "You need DataKinds for this program, and you don't have it on, but you 
> > will need it in the next release".   I don't want us to grandfather 
> > bugs into GHC indefinitely -- although you could argue that the status 
> > quo does little harm, I suppose.
> >
> > Any views?   We will have some idea of the impact on head.hackage shortly.
> >
> > *And specifically: do you want a GHC proposal for this change?*
> >
> > Simon
> > _______________________________________________
> > 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/20230925/1219ad0a/attachment-0001.html>

From lists at richarde.dev  Mon Sep 25 13:36:32 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 25 Sep 2023 13:36:32 +0000
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz_FHkzvxRYLzZcE0sODN8YNf-6VxE1DtMeS6PEtJC=hJA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAJKmMz_FHkzvxRYLzZcE0sODN8YNf-6VxE1DtMeS6PEtJC=hJA@mail.gmail.com>
Message-ID: <010f018acc8e4bbb-f00b070b-4633-4e13-a8c3-5043816c8eac-000000@us-east-2.amazonses.com>

In a discussion with Simon this morning, we realized that the document does two separable things:

1. It articulates a set of rules for what stability guarantees GHC should strive for
2. It articulates a possible enforcement mechanism for Haskellers to opt for the stable subset of GHC/Haskelll

It is possible to adopt (1) without (2). Indeed I worry that (2) would require much of the structure that we have already seen in Safe Haskell: a way to mark a package as "stable-interface" that somehow promises always to work, even though it uses experimental features internally. This will be necessary for `base`, for example, but I imagine other packages, too.

But even (1) on its own would at least align the committee and make forward progress easier to talk about.

I'm not necessarily against (2) -- just wanted to highlight that the two notions are separable.

Richard

> On Sep 25, 2023, at 4:46 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> A strong stability guarantee is certainly a valuable goal, but it also 
> comes with costs, which I'd like to see more clearly articulated. Some 
> of them include:
> 
> Thanks for articulating this.
> 
> I see this doc as the language counterpart of the base-libraries document, where we split `base` and `ghc-experimental`.  By splitting in this way, we allow innovation, while placing stronger stability goals on `base`.  Stronger,  but not unbreakable: I expect base to continue to evolve, e.g. by removing (with deprecation cycles) stuff that is plainly GHC-internal, subject to the CLC.  But, as we have seen in the extensive debate that led up to this proposal, it is really helpful to have a clear line between "experimental" and "stable", for all sorts of reasons.
> 
> I think we are just doing the same here.  Many GHC proposals add a new language feature, guarded by an extension, and are unaffected by the proposal.  Others make changes to recently added extensions (Linear Haskell is the poster child example), which we informally regard as experimental and subject to change. But we don't *say* that at the moment... it's all informal.  By identifying which extensions are experimental, and which are stable (and subject to higher back-compat goals) we help our users, and ourselves.  Just like base vs ghc-experimental.
> 
> I called them "General Rules" because (just like changes to base) I think we will want to break them.  But I'm content to be considerably more careful when we break stable extensions than experimental ones.
> 
> =============
> 
> Template Haskell is a real problem.  I don't think we can promise never to change TH syntax, for the reasons you describe.  
> 
> Is it true that many TH users use only splices and quotations, not explicit use of TH data constructors?  Those programs should be much more stable. 
> 
> For ones that use TH data constructors I think that prompt (but very routine) maintenance may be needed.
> 
> Simon
> 
> 
> 
> 
> On Mon, 25 Sept 2023 at 08:17, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
> I'm afraid that I'm somewhat sceptical of this approach.
> 
> A strong stability guarantee is certainly a valuable goal, but it also 
> comes with costs, which I'd like to see more clearly articulated. Some 
> of them include:
> 
>   * Cognitive overhead for users, because of the inability to remove 
> complexity from the design.
> 
>   * Increasing maintenance burden in the compiler, because of the 
> additional work needed to implement new features and the inability to 
> remove complexity from the implementation.
> 
>   * A risk of getting stuck in a local optimum, because moving to a 
> better design would entail breaking changes.
> 
>   * Discouraging volunteer contributors, who are much less likely to 
> work on a potentially beneficial change if the process for getting it 
> approved is too onerous. (I'm worried we're already reaching that point 
> due to the increasing burden of well-intentioned processes.)
> 
> Ultimately every proposed change has a cost-benefit trade-off, with risk 
> of breakage being one of the costs. We need to consciously evaluate that 
> trade-off on a case-by-case basis. Almost all changes might break 
> something (e.g. by regressing performance, or for Hyrum's Law reasons), 
> so there needs to be a proportionate assessment of how likely each 
> change is to be damaging in practice, bearing in mind that such an 
> assessment is itself costly and limited in scope.
> 
> It seems to me that the GHC team have taken on board lessons regarding 
> stability of the language, and the extension system already gives quite 
> a lot of flexibility to evolve the language in a backwards-compatible 
> way. In my experience, the key stability problems preventing upgrades to 
> recent GHC releases are:
> 
>   * The cascading effect of breaking changes in one library causing the 
> need to upgrade libraries which depend upon it. This is primarily under 
> the control of the CLC and library maintainers, however, not the GHC 
> team. It would help if base was minimal and reinstallable, but that 
> isn't a total solution either, because you'd still have to worry about 
> packages depending on template-haskell or the ghc package itself.
> 
>   * Performance regressions or critical bugs. These tend to be a 
> significant obstacle to upgrading for smaller commercial users. But 
> spending more of our limited resources on stability of the language 
> means fewer resources for resolving these issues.
> 
> There's surely more we can do here, but let's be careful not to pay too 
> many costs to achieve stability of the *language* alone, when stability 
> of the *libraries* and *implementation* are both more important and 
> harder to fix.
> 
> Adam
> 
> 
> On 22/09/2023 10:53, Simon Peyton Jones wrote:
> > Dear GHC SC
> > 
> > To avoid derailing the debate about -Wsevere 
> > <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>>, I'm starting a new (email for now) thread about stability.
> > 
> > I have tried to articulate what I believe is an evolving consensus in 
> > this document 
> > <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>>.
> > 
> > If we converge, we'll turn that into a proper PR for the GHC proposal 
> > process, although it has wider implications than just GHC proposals and 
> > we should share with a broader audience.  But let's start with the 
> > steering committee.
> > 
> > Any views?  You all have edit rights.
> > 
> > I think that the draft covers Moritz's and Julian's goals, at least that 
> > was my intention.  I have pasted Moritz's last email below, for context.
> > 
> > Simon
> > 
> > 
> > ========= Moritz's last email ============
> > 
> > Now, this is derailing the original discussion a bit, and I'm not sure 
> > how far we want to take this. But, regarding @Simon Marlow 
> > <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>'s comment
> > 
> >     This is one cultural aspect of our community I'd like to shift: the
> >     expectation that it's OK to make breaking changes as long as you
> >     warn about
> >     them or go through a migration cycle. It just isn't! (and I speak as
> >     someone who used to make lots of changes, I'm now fully repentant!).
> >     That's
> >     not to say that we shouldn't ever change anything, but when
> >     considering the
> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
> >     cost, it
> >     just defers it.
> > 
> > 
> > I actually read this as we should stop having breaking changes to begin 
> > with. And _if_ we
> > do have breaking changes, that deprecation does not change the need to 
> > actually change
> > code (cost). As outlined in my reply to that, and @Richard Eisenberg 
> > <mailto:lists at richarde.dev <mailto:lists at richarde.dev>>'s observation, it
> > "smears" the cost. The--to me--_much_ bigger implication of deprecation 
> > cycles is that we
> > _inform_ our _customers_ about upcoming changes _early_, instead of 
> > _after the fact_. We
> > also give them ample time to react. Being by changing their code, or 
> > raising their concerns.
> > Would the Simplified Subsumptions / Deep Subsumptions change have looked 
> > differently?
> > As such I see deprecation cycles as orthogonal to the question if we 
> > should have breaking
> > changes to begin with.
> > 
> > Thus I believe the following:
> > 
> >     - Do have a deprecation cycle if possible.
> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
> >     but are as large as ever.
> > 
> > 
> > should be upgraded to:
> > - Preferably _no_ breaking changes.
> > - If breaking changes, then with a deprecation cycle, unless technically 
> > infeasible.
> > - An understanding that any breaking change incurs significant costs.
> > 
> > Ocaml recently added multicore support, and they put tremendous effort 
> > into making
> > sure it keeps backwards compatibility: 
> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md> 
> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>>
> > 
> >     PS: we should also agree that a "stable" extension should not
> >     require dependencies on ghc-experimental.  To become stable, any
> >     library support for an extension must move into `base`.
> > 
> > 
> > This seems like a good idea, however I still remain that _experimental_ 
> > features should not be on-by-default in a stable compiler. Yes, ideally 
> > I'd not even see them in a stable compiler, but I know this view is 
> > contentious. The use of `ghc-experimental` should therefore be guarded 
> > by `--std=experimental` as Julian suggested. That is a loud opt-in to 
> > experimental features.
> > 
> 
> -- 
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/ <https://www.well-typed.com/>
> 
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
> 
> _______________________________________________
> 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/20230925/58e8d87d/attachment-0001.html>

From simon.peytonjones at gmail.com  Mon Sep 25 16:26:23 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 25 Sep 2023 17:26:23 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <010f018acc8e4bbb-f00b070b-4633-4e13-a8c3-5043816c8eac-000000@us-east-2.amazonses.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAJKmMz_FHkzvxRYLzZcE0sODN8YNf-6VxE1DtMeS6PEtJC=hJA@mail.gmail.com>
 <010f018acc8e4bbb-f00b070b-4633-4e13-a8c3-5043816c8eac-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz8N6sPa-rxVsoitsJy-zn6w=hQ_RmDFae535E1LrnodmA@mail.gmail.com>

>
> In a discussion with Simon this morning, we realized that the document
> does two separable things:
>
> 1. It articulates a set of rules for what stability guarantees GHC should
> strive for
> 2. It articulates a possible enforcement mechanism for Haskellers to opt
> for the stable subset of GHC/Haskelll
>

...and I have reflected this observation in the doc by pulling out (2) into
a new Section 6.

Simon

On Mon, 25 Sept 2023 at 14:36, Richard Eisenberg <lists at richarde.dev> wrote:

> In a discussion with Simon this morning, we realized that the document
> does two separable things:
>
> 1. It articulates a set of rules for what stability guarantees GHC should
> strive for
> 2. It articulates a possible enforcement mechanism for Haskellers to opt
> for the stable subset of GHC/Haskelll
>
> It is possible to adopt (1) without (2). Indeed I worry that (2) would
> require much of the structure that we have already seen in Safe Haskell: a
> way to mark a package as "stable-interface" that somehow promises always to
> work, even though it uses experimental features internally. This will be
> necessary for `base`, for example, but I imagine other packages, too.
>
> But even (1) on its own would at least align the committee and make
> forward progress easier to talk about.
>
> I'm not necessarily against (2) -- just wanted to highlight that the two
> notions are separable.
>
> Richard
>
> On Sep 25, 2023, at 4:46 AM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
> A strong stability guarantee is certainly a valuable goal, but it also
>> comes with costs, which I'd like to see more clearly articulated. Some
>> of them include:
>>
>
> Thanks for articulating this.
>
> I see this doc as the language counterpart of the base-libraries document,
> where we split `base` and `ghc-experimental`.  By splitting in this way, we
> allow innovation, while placing stronger stability goals on `base`.
> Stronger,  but not unbreakable: I expect base to continue to evolve, e.g.
> by removing (with deprecation cycles) stuff that is plainly GHC-internal,
> subject to the CLC.  But, as we have seen in the extensive debate that led
> up to this proposal, it is *really *helpful to have a clear line between
> "experimental" and "stable", for all sorts of reasons.
>
> I think we are just doing the same here.  Many GHC proposals add a new
> language feature, guarded by an extension, and are unaffected by the
> proposal.  Others make changes to recently added extensions (Linear Haskell
> is the poster child example), which we informally regard as experimental
> and subject to change. But we don't *say* that at the moment... it's all
> informal.  By identifying which extensions are experimental, and which are
> stable (and subject to higher back-compat goals) we help our users, and
> ourselves.  Just like base vs ghc-experimental.
>
> I called them "General Rules" because (just like changes to base) I think
> we will want to break them.  But I'm content to be considerably more
> careful when we break stable extensions than experimental ones.
>
> =============
>
> Template Haskell is a real problem.  I don't think we can promise never to
> change TH syntax, for the reasons you describe.
>
> Is it true that many TH users use only splices and quotations, not
> explicit use of TH data constructors?  Those programs should be much more
> stable.
>
> For ones that use TH data constructors I think that prompt (but very
> routine) maintenance may be needed.
>
> Simon
>
>
>
>
> On Mon, 25 Sept 2023 at 08:17, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm afraid that I'm somewhat sceptical of this approach.
>>
>> A strong stability guarantee is certainly a valuable goal, but it also
>> comes with costs, which I'd like to see more clearly articulated. Some
>> of them include:
>>
>>   * Cognitive overhead for users, because of the inability to remove
>> complexity from the design.
>>
>>   * Increasing maintenance burden in the compiler, because of the
>> additional work needed to implement new features and the inability to
>> remove complexity from the implementation.
>>
>>   * A risk of getting stuck in a local optimum, because moving to a
>> better design would entail breaking changes.
>>
>>   * Discouraging volunteer contributors, who are much less likely to
>> work on a potentially beneficial change if the process for getting it
>> approved is too onerous. (I'm worried we're already reaching that point
>> due to the increasing burden of well-intentioned processes.)
>>
>> Ultimately every proposed change has a cost-benefit trade-off, with risk
>> of breakage being one of the costs. We need to consciously evaluate that
>> trade-off on a case-by-case basis. Almost all changes might break
>> something (e.g. by regressing performance, or for Hyrum's Law reasons),
>> so there needs to be a proportionate assessment of how likely each
>> change is to be damaging in practice, bearing in mind that such an
>> assessment is itself costly and limited in scope.
>>
>> It seems to me that the GHC team have taken on board lessons regarding
>> stability of the language, and the extension system already gives quite
>> a lot of flexibility to evolve the language in a backwards-compatible
>> way. In my experience, the key stability problems preventing upgrades to
>> recent GHC releases are:
>>
>>   * The cascading effect of breaking changes in one library causing the
>> need to upgrade libraries which depend upon it. This is primarily under
>> the control of the CLC and library maintainers, however, not the GHC
>> team. It would help if base was minimal and reinstallable, but that
>> isn't a total solution either, because you'd still have to worry about
>> packages depending on template-haskell or the ghc package itself.
>>
>>   * Performance regressions or critical bugs. These tend to be a
>> significant obstacle to upgrading for smaller commercial users. But
>> spending more of our limited resources on stability of the language
>> means fewer resources for resolving these issues.
>>
>> There's surely more we can do here, but let's be careful not to pay too
>> many costs to achieve stability of the *language* alone, when stability
>> of the *libraries* and *implementation* are both more important and
>> harder to fix.
>>
>> Adam
>>
>>
>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>> > Dear GHC SC
>> >
>> > To avoid derailing the debate about -Wsevere
>> > <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>> and HasField redesign <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>> I'm starting a new (email for now) thread about stability.
>> >
>> > I have tried to articulate what I believe is an evolving consensus in
>> > this document
>> > <
>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>> >.
>> >
>> > If we converge, we'll turn that into a proper PR for the GHC proposal
>> > process, although it has wider implications than just GHC proposals and
>> > we should share with a broader audience.  But let's start with the
>> > steering committee.
>> >
>> > Any views?  You all have edit rights.
>> >
>> > I think that the draft covers Moritz's and Julian's goals, at least
>> that
>> > was my intention.  I have pasted Moritz's last email below, for context.
>> >
>> > Simon
>> >
>> >
>> > ========= Moritz's last email ============
>> >
>> > Now, this is derailing the original discussion a bit, and I'm not sure
>> > how far we want to take this. But, regarding @Simon Marlow
>> > <mailto:marlowsd at gmail.com>'s comment
>> >
>> >     This is one cultural aspect of our community I'd like to shift: the
>> >     expectation that it's OK to make breaking changes as long as you
>> >     warn about
>> >     them or go through a migration cycle. It just isn't! (and I speak as
>> >     someone who used to make lots of changes, I'm now fully repentant!).
>> >     That's
>> >     not to say that we shouldn't ever change anything, but when
>> >     considering the
>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>> >     cost, it
>> >     just defers it.
>> >
>> >
>> > I actually read this as we should stop having breaking changes to begin
>> > with. And _if_ we
>> > do have breaking changes, that deprecation does not change the need to
>> > actually change
>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>> > <mailto:lists at richarde.dev>'s observation, it
>> > "smears" the cost. The--to me--_much_ bigger implication of deprecation
>> > cycles is that we
>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>> > _after the fact_. We
>> > also give them ample time to react. Being by changing their code, or
>> > raising their concerns.
>> > Would the Simplified Subsumptions / Deep Subsumptions change
>> have looked
>> > differently?
>> > As such I see deprecation cycles as orthogonal to the question if we
>> > should have breaking
>> > changes to begin with.
>> >
>> > Thus I believe the following:
>> >
>> >     - Do have a deprecation cycle if possible.
>> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>> >     but are as large as ever.
>> >
>> >
>> > should be upgraded to:
>> > - Preferably _no_ breaking changes.
>> > - If breaking changes, then with a deprecation cycle, unless
>> technically
>> > infeasible.
>> > - An understanding that any breaking change incurs significant costs.
>> >
>> > Ocaml recently added multicore support, and they put tremendous effort
>> > into making
>> > sure it keeps backwards compatibility:
>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>> >
>> >     PS: we should also agree that a "stable" extension should not
>> >     require dependencies on ghc-experimental.  To become stable, any
>> >     library support for an extension must move into `base`.
>> >
>> >
>> > This seems like a good idea, however I still remain that _experimental_
>> > features should not be on-by-default in a stable compiler. Yes, ideally
>> > I'd not even see them in a stable compiler, but I know this view is
>> > contentious. The use of `ghc-experimental` should therefore be guarded
>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
>> > experimental features.
>> >
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230925/28ee6e58/attachment-0001.html>

From chris at chrisdornan.com  Tue Sep 26 03:13:19 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 26 Sep 2023 04:13:19 +0100
Subject: [ghc-steering-committee] Warnings
In-Reply-To: <010f018acc888394-7093842b-42eb-4270-9359-8044154865f3-000000@us-east-2.amazonses.com>
References: <CAJKmMz96RWiPfaB+3FXGdntAEd3p+txZCSBWwjTW10dUwCtNrA@mail.gmail.com>
 <bccc3f43-3c32-4ec9-bbca-82d7d953805b@app.fastmail.com>
 <CAKfdd-ymU=DkNOiYSLPomkw8ig=jS8=Lm0heviRs5PnAVmrOQQ@mail.gmail.com>
 <010f018acc888394-7093842b-42eb-4270-9359-8044154865f3-000000@us-east-2.amazonses.com>
Message-ID: <E9ABE4CE-7BDB-47FA-8F13-34BC7B33AC7E@chrisdornan.com>

Indeed a bugfix with deprecation cycle seems entirely right.

> On 25 Sep 2023, at 14:30, Richard Eisenberg <lists at richarde.dev> wrote:
> 
> Yes, let's fix the bug with a deprecation cycle.
> 
>> On Sep 25, 2023, at 8:43 AM, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> 
>> I actually think a warning/deprecation period should be down in this case. It doesn’t break code right now. It is not critical for this to be fixed immediately (nothing significantly averse will happen to someone accidentally using this).
>> 
>> I’m willing to put some of IOGs resources at helping with implementing the deprecation warnings; leading by example, hoping this will inspire others to do the same in the future. 
>> 
>> Best,
>>  Moritz
>> 
>> On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
>>> I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix. 
>>> 
>>> I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)
>>> 
>>> On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:
>>> > Dear GHC SC
>>> >
>>> > You may or may not have been following GHC ticket #22141 
>>> > <https://gitlab.haskell.org/ghc/ghc/-/issues/22141>, and Ryan's merge 
>>> > request !11314 
>>> > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314>.
>>> >
>>> > The story is this:
>>> >  • There is a bug in GHC that allows programs to use DataKinds without 
>>> > the -XDataKinds extension.
>>> >  • The MR fixes the bug.
>>> >  • But of course that will mean that some programs that previously 
>>> > compiled (exploiting the bug) will now fail to compile (correctly).
>>> > It seems like an example of our (GR2) discussion, but with a very 
>>> > different flavour than the  (3+4=8) example.
>>> >
>>> > Personally I think we should do it -- with a deprecation cycle saying 
>>> > "You need DataKinds for this program, and you don't have it on, but you 
>>> > will need it in the next release".   I don't want us to grandfather 
>>> > bugs into GHC indefinitely -- although you could argue that the status 
>>> > quo does little harm, I suppose.
>>> >
>>> > Any views?   We will have some idea of the impact on head.hackage shortly.
>>> >
>>> > *And specifically: do you want a GHC proposal for this change?*
>>> >
>>> > Simon
>>> > _______________________________________________
>>> > 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> 
> _______________________________________________
> 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/20230926/673ba10c/attachment.html>

From moritz.angermann at gmail.com  Wed Sep 27 09:19:38 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Wed, 27 Sep 2023 17:19:38 +0800
Subject: [ghc-steering-committee] Stability
In-Reply-To: <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
Message-ID: <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>

Dear Adam,

Thank you for your thoughtful feedback. I understand your reservations, and
it's essential that we continue to have these discussions to ensure we're
making the best decisions for the project and our community. Let me address
each of your points in turn:
- Cognitive Overhead for Users:
I understand the concern about cognitive overhead due to the inability to
remove complexity. However, our primary intention is to ensure a gradual
transition for our users rather than abrupt shifts. Introducing changes via
deprecation cycles allows users to adjust to modifications over time,
reducing the immediate cognitive load. It's a balance between stability and
simplicity, and I believe this approach allows us still to reduce
complexity.

- Maintenance Burden in the Compiler:
Maintaining backward compatibility does indeed introduce some overhead.
Still, it also encourages a more disciplined and considered approach to
changes. With our deprecation cycles in place, it's not that we never
remove complexity; rather, we do it in a way that provides ample time for
adjustments. This benefits both the development team and the community.

- Risk of Local Optimum:
This is a valid concern. However, deprecation cycles don't mean we're
averse to major changes. It means we introduce them responsibly. When we
believe a superior design is possible, we can start a deprecation process
to transition towards it. The flexibility and duration of our deprecation
cycles can be tailored depending on the severity of the breaking change.

- Discouraging Volunteer Contributors:
I understand that lengthy approval processes can be off-putting. But it's
crucial to note that a rigorous process ensures the consistency and
reliability of our project. We always welcome and value contributions.
Moreover, I believe this stability policy will provide us with clear
guardrails on how changes can be contributed.

I will not disagree on the costs. I do believe though that the costs for
_breaking_ changes in the compiler ought to be borne by the people making
the change, instead of those who use the compiler (and may not even benefit
of those changes that caused breakage). I also see the team maintaining GHC
as the one to enforce this; they are the ones who cut the releases. The
fact that we may have breaking changes due to _bugs_ is covered explicitly
in the stability policy document.

With my CLC hat on, I have been focusing on the same stability guidelines
as well (if it breaks existing code, I have been against those changes
without deprecation policies). The issues with the template-haskell, and
ghc library are noted. For the ghc library the question will remain if we
intent to provide a stable api to the compiler or not. I believe many tools
would like to have one, and if we relegate anything unstable to
ghc-experimental this might be achieved. For template-haskell this is a
bigger concern. Maybe we can collectively come up with a solution that
would allow us to provide a more insulated template haskell interface from
the compiler.

However for template-haskell we might also need to look at what exactly
caused those breaking changes in the past.

What this document outlines (in my understanding) is that any experimental
feature development can _only_ be visible behind --std=experimental, and
the dependency of ghc-experimental. Unless those are given, the compiler
should accept existing programs. This should allow us enough room to
innovate (everyone is always free to opt-in to bleeding edge features with
--std=experimental).  I also believe that most of what we have today will
need to be treated as non-experimental simply because we did not have that
mechanism before. We don't want to break existing programs as much as
possible, thus relegating existing features into --std=experimental (except
for some fairly clear ones: e.g. Dependent Haskell, and Linear Types?) is
not really possible. What we can however do is start deprecation phases for
a few versions, moving features we consider highly experimental (or maybe
even bad) into `--std=experimental`. Just by having deprecation phases and
given the ecosystem enough time to adjust (and provide feedback) we might
come to different conclusions.

As I've also outlined in the document, _if_ GHC was trivially swappable,
companies like IOG would _love_ to try new compilers and report back bugs
and regressions. As it is today, we can't. Making a large live codebase
compatible with 9.8 is a multiple weeks effort. Experimenting with
nightlies is technically impossible. _If_ I could setup the built of our
software trivial with ghc nightlies, I'd be _happy_ to build the
infrastructure out it to provide performance regressions (compilation,
runtime, ...) for our codebase and provide the feedback to the GHC team;
however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
going to see any further releases, so I can spare trying to even forward
port my patches to HEAD. Not that I could even test them with head
properly, as our source is not accepted by HEAD. Thus I end up writing
patches against old stale branches. This to me is a fairly big
discouragement from contributing to GHC.

Best,
 Moritz

On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com> wrote:

> I'm afraid that I'm somewhat sceptical of this approach.
>
> A strong stability guarantee is certainly a valuable goal, but it also
> comes with costs, which I'd like to see more clearly articulated. Some
> of them include:
>
>   * Cognitive overhead for users, because of the inability to remove
> complexity from the design.
>
>   * Increasing maintenance burden in the compiler, because of the
> additional work needed to implement new features and the inability to
> remove complexity from the implementation.
>
>   * A risk of getting stuck in a local optimum, because moving to a
> better design would entail breaking changes.
>
>   * Discouraging volunteer contributors, who are much less likely to
> work on a potentially beneficial change if the process for getting it
> approved is too onerous. (I'm worried we're already reaching that point
> due to the increasing burden of well-intentioned processes.)
>
> Ultimately every proposed change has a cost-benefit trade-off, with risk
> of breakage being one of the costs. We need to consciously evaluate that
> trade-off on a case-by-case basis. Almost all changes might break
> something (e.g. by regressing performance, or for Hyrum's Law reasons),
> so there needs to be a proportionate assessment of how likely each
> change is to be damaging in practice, bearing in mind that such an
> assessment is itself costly and limited in scope.
>
> It seems to me that the GHC team have taken on board lessons regarding
> stability of the language, and the extension system already gives quite
> a lot of flexibility to evolve the language in a backwards-compatible
> way. In my experience, the key stability problems preventing upgrades to
> recent GHC releases are:
>
>   * The cascading effect of breaking changes in one library causing the
> need to upgrade libraries which depend upon it. This is primarily under
> the control of the CLC and library maintainers, however, not the GHC
> team. It would help if base was minimal and reinstallable, but that
> isn't a total solution either, because you'd still have to worry about
> packages depending on template-haskell or the ghc package itself.
>
>   * Performance regressions or critical bugs. These tend to be a
> significant obstacle to upgrading for smaller commercial users. But
> spending more of our limited resources on stability of the language
> means fewer resources for resolving these issues.
>
> There's surely more we can do here, but let's be careful not to pay too
> many costs to achieve stability of the *language* alone, when stability
> of the *libraries* and *implementation* are both more important and
> harder to fix.
>
> Adam
>
>
> On 22/09/2023 10:53, Simon Peyton Jones wrote:
> > Dear GHC SC
> >
> > To avoid derailing the debate about -Wsevere
> > <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
> and HasField redesign <
> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
> I'm starting a new (email for now) thread about stability.
> >
> > I have tried to articulate what I believe is an evolving consensus in
> > this document
> > <
> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
> >.
> >
> > If we converge, we'll turn that into a proper PR for the GHC proposal
> > process, although it has wider implications than just GHC proposals and
> > we should share with a broader audience.  But let's start with the
> > steering committee.
> >
> > Any views?  You all have edit rights.
> >
> > I think that the draft covers Moritz's and Julian's goals, at least that
> > was my intention.  I have pasted Moritz's last email below, for context.
> >
> > Simon
> >
> >
> > ========= Moritz's last email ============
> >
> > Now, this is derailing the original discussion a bit, and I'm not sure
> > how far we want to take this. But, regarding @Simon Marlow
> > <mailto:marlowsd at gmail.com>'s comment
> >
> >     This is one cultural aspect of our community I'd like to shift: the
> >     expectation that it's OK to make breaking changes as long as you
> >     warn about
> >     them or go through a migration cycle. It just isn't! (and I speak as
> >     someone who used to make lots of changes, I'm now fully repentant!).
> >     That's
> >     not to say that we shouldn't ever change anything, but when
> >     considering the
> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
> >     cost, it
> >     just defers it.
> >
> >
> > I actually read this as we should stop having breaking changes to begin
> > with. And _if_ we
> > do have breaking changes, that deprecation does not change the need to
> > actually change
> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
> > <mailto:lists at richarde.dev>'s observation, it
> > "smears" the cost. The--to me--_much_ bigger implication of deprecation
> > cycles is that we
> > _inform_ our _customers_ about upcoming changes _early_, instead of
> > _after the fact_. We
> > also give them ample time to react. Being by changing their code, or
> > raising their concerns.
> > Would the Simplified Subsumptions / Deep Subsumptions change have looked
> > differently?
> > As such I see deprecation cycles as orthogonal to the question if we
> > should have breaking
> > changes to begin with.
> >
> > Thus I believe the following:
> >
> >     - Do have a deprecation cycle if possible.
> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
> >     but are as large as ever.
> >
> >
> > should be upgraded to:
> > - Preferably _no_ breaking changes.
> > - If breaking changes, then with a deprecation cycle, unless technically
> > infeasible.
> > - An understanding that any breaking change incurs significant costs.
> >
> > Ocaml recently added multicore support, and they put tremendous effort
> > into making
> > sure it keeps backwards compatibility:
> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
> >
> >     PS: we should also agree that a "stable" extension should not
> >     require dependencies on ghc-experimental.  To become stable, any
> >     library support for an extension must move into `base`.
> >
> >
> > This seems like a good idea, however I still remain that _experimental_
> > features should not be on-by-default in a stable compiler. Yes, ideally
> > I'd not even see them in a stable compiler, but I know this view is
> > contentious. The use of `ghc-experimental` should therefore be guarded
> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
> > experimental features.
> >
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> 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/20230927/5e46894b/attachment-0001.html>

From mail at joachim-breitner.de  Wed Sep 27 14:12:41 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 27 Sep 2023 16:12:41 +0200
Subject: [ghc-steering-committee] Please review #612: -fhpc tix file changes,
 Shepherd: Moritz
Message-ID: <d0af52d154a3d2ae47998004ffce789a6f07f017.camel@joachim-breitner.de>

Dear Committee,

David Binder suggests to change how -fhpc handles existing tix files
by default:

https://github.com/ghc-proposals/ghc-proposals/pull/612
https://github.com/BinderDavid/ghc-proposals/blob/change-fhpc-semantics/proposals/0000-template.md
I’d like to nominate Moritz as the shepherd.

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


Cheers,
Joachim






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


From simon.peytonjones at gmail.com  Wed Sep 27 14:35:36 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 27 Sep 2023 15:35:36 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
Message-ID: <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>

>
> it's essential that we continue to have these discussions to ensure we're
> making the best decisions for the project and our community.
>

Yes exactly!  Its tricky and nuanced; hence trying to articulate something
in a concrete doc, so we are all on the same page (literally!).

However, deprecation cycles don't mean we're averse to major changes. It
> means we introduce them responsibly. When we believe a superior design is
> possible, we can start a deprecation process to transition towards it.
>

I have tried to make this explicit in Section 4.   See what you think.

I think there are three phases

   1. Agree this document.  Is it what we want.
   2. Categorise extensions into stable/experimental, and identify
   experimental language features.
   3. Implement --std=experimental (Section 6).

(1) is what we are doing now.  (2) will be some work, done by us.  (3) is a
larger task: it will require significant work to implement, and may impose
unwelcome churn of its own.  But that should not stop us doing (1) and (2).

Simon

   -


On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear Adam,
>
> Thank you for your thoughtful feedback. I understand your reservations,
> and it's essential that we continue to have these discussions to ensure
> we're making the best decisions for the project and our community. Let me
> address each of your points in turn:
> - Cognitive Overhead for Users:
> I understand the concern about cognitive overhead due to the inability to
> remove complexity. However, our primary intention is to ensure a gradual
> transition for our users rather than abrupt shifts. Introducing changes via
> deprecation cycles allows users to adjust to modifications over time,
> reducing the immediate cognitive load. It's a balance between stability and
> simplicity, and I believe this approach allows us still to reduce
> complexity.
>
> - Maintenance Burden in the Compiler:
> Maintaining backward compatibility does indeed introduce some overhead.
> Still, it also encourages a more disciplined and considered approach to
> changes. With our deprecation cycles in place, it's not that we never
> remove complexity; rather, we do it in a way that provides ample time for
> adjustments. This benefits both the development team and the community.
>
> - Risk of Local Optimum:
> This is a valid concern. However, deprecation cycles don't mean we're
> averse to major changes. It means we introduce them responsibly. When we
> believe a superior design is possible, we can start a deprecation process
> to transition towards it. The flexibility and duration of our deprecation
> cycles can be tailored depending on the severity of the breaking change.
>
> - Discouraging Volunteer Contributors:
> I understand that lengthy approval processes can be off-putting. But it's
> crucial to note that a rigorous process ensures the consistency and
> reliability of our project. We always welcome and value contributions.
> Moreover, I believe this stability policy will provide us with clear
> guardrails on how changes can be contributed.
>
> I will not disagree on the costs. I do believe though that the costs for
> _breaking_ changes in the compiler ought to be borne by the people making
> the change, instead of those who use the compiler (and may not even benefit
> of those changes that caused breakage). I also see the team maintaining GHC
> as the one to enforce this; they are the ones who cut the releases. The
> fact that we may have breaking changes due to _bugs_ is covered explicitly
> in the stability policy document.
>
> With my CLC hat on, I have been focusing on the same stability guidelines
> as well (if it breaks existing code, I have been against those changes
> without deprecation policies). The issues with the template-haskell, and
> ghc library are noted. For the ghc library the question will remain if we
> intent to provide a stable api to the compiler or not. I believe many tools
> would like to have one, and if we relegate anything unstable to
> ghc-experimental this might be achieved. For template-haskell this is a
> bigger concern. Maybe we can collectively come up with a solution that
> would allow us to provide a more insulated template haskell interface from
> the compiler.
>
> However for template-haskell we might also need to look at what exactly
> caused those breaking changes in the past.
>
> What this document outlines (in my understanding) is that any experimental
> feature development can _only_ be visible behind --std=experimental, and
> the dependency of ghc-experimental. Unless those are given, the compiler
> should accept existing programs. This should allow us enough room to
> innovate (everyone is always free to opt-in to bleeding edge features with
> --std=experimental).  I also believe that most of what we have today will
> need to be treated as non-experimental simply because we did not have that
> mechanism before. We don't want to break existing programs as much as
> possible, thus relegating existing features into --std=experimental (except
> for some fairly clear ones: e.g. Dependent Haskell, and Linear Types?) is
> not really possible. What we can however do is start deprecation phases for
> a few versions, moving features we consider highly experimental (or maybe
> even bad) into `--std=experimental`. Just by having deprecation phases and
> given the ecosystem enough time to adjust (and provide feedback) we might
> come to different conclusions.
>
> As I've also outlined in the document, _if_ GHC was trivially swappable,
> companies like IOG would _love_ to try new compilers and report back bugs
> and regressions. As it is today, we can't. Making a large live codebase
> compatible with 9.8 is a multiple weeks effort. Experimenting with
> nightlies is technically impossible. _If_ I could setup the built of our
> software trivial with ghc nightlies, I'd be _happy_ to build the
> infrastructure out it to provide performance regressions (compilation,
> runtime, ...) for our codebase and provide the feedback to the GHC team;
> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
> going to see any further releases, so I can spare trying to even forward
> port my patches to HEAD. Not that I could even test them with head
> properly, as our source is not accepted by HEAD. Thus I end up writing
> patches against old stale branches. This to me is a fairly big
> discouragement from contributing to GHC.
>
> Best,
>  Moritz
>
> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com> wrote:
>
>> I'm afraid that I'm somewhat sceptical of this approach.
>>
>> A strong stability guarantee is certainly a valuable goal, but it also
>> comes with costs, which I'd like to see more clearly articulated. Some
>> of them include:
>>
>>   * Cognitive overhead for users, because of the inability to remove
>> complexity from the design.
>>
>>   * Increasing maintenance burden in the compiler, because of the
>> additional work needed to implement new features and the inability to
>> remove complexity from the implementation.
>>
>>   * A risk of getting stuck in a local optimum, because moving to a
>> better design would entail breaking changes.
>>
>>   * Discouraging volunteer contributors, who are much less likely to
>> work on a potentially beneficial change if the process for getting it
>> approved is too onerous. (I'm worried we're already reaching that point
>> due to the increasing burden of well-intentioned processes.)
>>
>> Ultimately every proposed change has a cost-benefit trade-off, with risk
>> of breakage being one of the costs. We need to consciously evaluate that
>> trade-off on a case-by-case basis. Almost all changes might break
>> something (e.g. by regressing performance, or for Hyrum's Law reasons),
>> so there needs to be a proportionate assessment of how likely each
>> change is to be damaging in practice, bearing in mind that such an
>> assessment is itself costly and limited in scope.
>>
>> It seems to me that the GHC team have taken on board lessons regarding
>> stability of the language, and the extension system already gives quite
>> a lot of flexibility to evolve the language in a backwards-compatible
>> way. In my experience, the key stability problems preventing upgrades to
>> recent GHC releases are:
>>
>>   * The cascading effect of breaking changes in one library causing the
>> need to upgrade libraries which depend upon it. This is primarily under
>> the control of the CLC and library maintainers, however, not the GHC
>> team. It would help if base was minimal and reinstallable, but that
>> isn't a total solution either, because you'd still have to worry about
>> packages depending on template-haskell or the ghc package itself.
>>
>>   * Performance regressions or critical bugs. These tend to be a
>> significant obstacle to upgrading for smaller commercial users. But
>> spending more of our limited resources on stability of the language
>> means fewer resources for resolving these issues.
>>
>> There's surely more we can do here, but let's be careful not to pay too
>> many costs to achieve stability of the *language* alone, when stability
>> of the *libraries* and *implementation* are both more important and
>> harder to fix.
>>
>> Adam
>>
>>
>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>> > Dear GHC SC
>> >
>> > To avoid derailing the debate about -Wsevere
>> > <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>> and HasField redesign <
>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>> I'm starting a new (email for now) thread about stability.
>> >
>> > I have tried to articulate what I believe is an evolving consensus in
>> > this document
>> > <
>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>> >.
>> >
>> > If we converge, we'll turn that into a proper PR for the GHC proposal
>> > process, although it has wider implications than just GHC proposals and
>> > we should share with a broader audience.  But let's start with the
>> > steering committee.
>> >
>> > Any views?  You all have edit rights.
>> >
>> > I think that the draft covers Moritz's and Julian's goals, at least
>> that
>> > was my intention.  I have pasted Moritz's last email below, for context.
>> >
>> > Simon
>> >
>> >
>> > ========= Moritz's last email ============
>> >
>> > Now, this is derailing the original discussion a bit, and I'm not sure
>> > how far we want to take this. But, regarding @Simon Marlow
>> > <mailto:marlowsd at gmail.com>'s comment
>> >
>> >     This is one cultural aspect of our community I'd like to shift: the
>> >     expectation that it's OK to make breaking changes as long as you
>> >     warn about
>> >     them or go through a migration cycle. It just isn't! (and I speak as
>> >     someone who used to make lots of changes, I'm now fully repentant!).
>> >     That's
>> >     not to say that we shouldn't ever change anything, but when
>> >     considering the
>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>> >     cost, it
>> >     just defers it.
>> >
>> >
>> > I actually read this as we should stop having breaking changes to begin
>> > with. And _if_ we
>> > do have breaking changes, that deprecation does not change the need to
>> > actually change
>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>> > <mailto:lists at richarde.dev>'s observation, it
>> > "smears" the cost. The--to me--_much_ bigger implication of deprecation
>> > cycles is that we
>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>> > _after the fact_. We
>> > also give them ample time to react. Being by changing their code, or
>> > raising their concerns.
>> > Would the Simplified Subsumptions / Deep Subsumptions change
>> have looked
>> > differently?
>> > As such I see deprecation cycles as orthogonal to the question if we
>> > should have breaking
>> > changes to begin with.
>> >
>> > Thus I believe the following:
>> >
>> >     - Do have a deprecation cycle if possible.
>> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>> >     but are as large as ever.
>> >
>> >
>> > should be upgraded to:
>> > - Preferably _no_ breaking changes.
>> > - If breaking changes, then with a deprecation cycle, unless
>> technically
>> > infeasible.
>> > - An understanding that any breaking change incurs significant costs.
>> >
>> > Ocaml recently added multicore support, and they put tremendous effort
>> > into making
>> > sure it keeps backwards compatibility:
>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>> >
>> >     PS: we should also agree that a "stable" extension should not
>> >     require dependencies on ghc-experimental.  To become stable, any
>> >     library support for an extension must move into `base`.
>> >
>> >
>> > This seems like a good idea, however I still remain that _experimental_
>> > features should not be on-by-default in a stable compiler. Yes, ideally
>> > I'd not even see them in a stable compiler, but I know this view is
>> > contentious. The use of `ghc-experimental` should therefore be guarded
>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
>> > experimental features.
>> >
>>
>> --
>> Adam Gundry, Haskell Consultant
>> Well-Typed LLP, https://www.well-typed.com/
>>
>> Registered in England & Wales, OC335890
>> 27 Old Gloucester Street, London WC1N 3AX, England
>>
>> _______________________________________________
>> 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/20230927/a893a193/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Sep 28 01:19:47 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 28 Sep 2023 09:19:47 +0800
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
Message-ID: <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>

I think we are moving in the right direction! I do see however the tension
rising on (2). And without being clear about (2), I don’t think we can
properly agree on (1). We can agree on (1) in principle, but we need to
clarify what we consider unstable/experimental, as a precondition to have
finale agreement on (1). Otherwise people might agree to (1), only to be
surprised by (2). For (3), I’d be happy to try to get my employer to
provide resources for the implementation of —std=experimental.

Thusly I believe we should start to build a list of features we consider
sufficiently experimental that they should preclude an existing Haskell
program from being considered stable. This list for me contains so far:

- Linear Types
- Dependent Haskell

Adam pointed out experimental backend and non-tire-1 platforms. I tend to
agree with this, but see this distinctly separate from the language
stability (outside of backend specific language extensions, e.g. JSFFI).

Platforms/backends may be experimental but those are (safe for specific
lang exts) orthogonal to the Haskell code the compiler accepts.

Should we have a document (or better spreadsheet?) with a bullet point for
each experimental feature to be considered? I believe we need to take into
account that we can’t end up classifying most of todays Haskell programs
unstable. As such I’d like to propose that we’d add to each features a
counter for how much of hackage (as a proxy for real world usage) uses the
specific feature.

Best,
 Moritz

On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> it's essential that we continue to have these discussions to ensure we're
>> making the best decisions for the project and our community.
>>
>
> Yes exactly!  Its tricky and nuanced; hence trying to articulate something
> in a concrete doc, so we are all on the same page (literally!).
>
> However, deprecation cycles don't mean we're averse to major changes. It
>> means we introduce them responsibly. When we believe a superior design is
>> possible, we can start a deprecation process to transition towards it.
>>
>
> I have tried to make this explicit in Section 4.   See what you think.
>
> I think there are three phases
>
>    1. Agree this document.  Is it what we want.
>    2. Categorise extensions into stable/experimental, and identify
>    experimental language features.
>    3. Implement --std=experimental (Section 6).
>
> (1) is what we are doing now.  (2) will be some work, done by us.  (3) is
> a larger task: it will require significant work to implement, and may
> impose unwelcome churn of its own.  But that should not stop us doing (1)
> and (2).
>
> Simon
>
>    -
>
>
> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> Dear Adam,
>>
>> Thank you for your thoughtful feedback. I understand your reservations,
>> and it's essential that we continue to have these discussions to ensure
>> we're making the best decisions for the project and our community. Let me
>> address each of your points in turn:
>> - Cognitive Overhead for Users:
>> I understand the concern about cognitive overhead due to the inability to
>> remove complexity. However, our primary intention is to ensure a gradual
>> transition for our users rather than abrupt shifts. Introducing changes via
>> deprecation cycles allows users to adjust to modifications over time,
>> reducing the immediate cognitive load. It's a balance between stability and
>> simplicity, and I believe this approach allows us still to reduce
>> complexity.
>>
>> - Maintenance Burden in the Compiler:
>> Maintaining backward compatibility does indeed introduce some overhead.
>> Still, it also encourages a more disciplined and considered approach to
>> changes. With our deprecation cycles in place, it's not that we never
>> remove complexity; rather, we do it in a way that provides ample time for
>> adjustments. This benefits both the development team and the community.
>>
>> - Risk of Local Optimum:
>> This is a valid concern. However, deprecation cycles don't mean we're
>> averse to major changes. It means we introduce them responsibly. When we
>> believe a superior design is possible, we can start a deprecation process
>> to transition towards it. The flexibility and duration of our deprecation
>> cycles can be tailored depending on the severity of the breaking change.
>>
>> - Discouraging Volunteer Contributors:
>> I understand that lengthy approval processes can be off-putting. But it's
>> crucial to note that a rigorous process ensures the consistency and
>> reliability of our project. We always welcome and value contributions.
>> Moreover, I believe this stability policy will provide us with clear
>> guardrails on how changes can be contributed.
>>
>> I will not disagree on the costs. I do believe though that the costs for
>> _breaking_ changes in the compiler ought to be borne by the people making
>> the change, instead of those who use the compiler (and may not even benefit
>> of those changes that caused breakage). I also see the team maintaining GHC
>> as the one to enforce this; they are the ones who cut the releases. The
>> fact that we may have breaking changes due to _bugs_ is covered explicitly
>> in the stability policy document.
>>
>> With my CLC hat on, I have been focusing on the same stability guidelines
>> as well (if it breaks existing code, I have been against those changes
>> without deprecation policies). The issues with the template-haskell, and
>> ghc library are noted. For the ghc library the question will remain if we
>> intent to provide a stable api to the compiler or not. I believe many tools
>> would like to have one, and if we relegate anything unstable to
>> ghc-experimental this might be achieved. For template-haskell this is a
>> bigger concern. Maybe we can collectively come up with a solution that
>> would allow us to provide a more insulated template haskell interface from
>> the compiler.
>>
>> However for template-haskell we might also need to look at what exactly
>> caused those breaking changes in the past.
>>
>> What this document outlines (in my understanding) is that any
>> experimental feature development can _only_ be visible behind
>> --std=experimental, and the dependency of ghc-experimental. Unless those
>> are given, the compiler should accept existing programs. This should allow
>> us enough room to innovate (everyone is always free to opt-in to bleeding
>> edge features with --std=experimental).  I also believe that most of what
>> we have today will need to be treated as non-experimental simply because we
>> did not have that mechanism before. We don't want to break existing
>> programs as much as possible, thus relegating existing features into
>> --std=experimental (except for some fairly clear ones: e.g. Dependent
>> Haskell, and Linear Types?) is not really possible. What we can however do
>> is start deprecation phases for a few versions, moving features we consider
>> highly experimental (or maybe even bad) into `--std=experimental`. Just by
>> having deprecation phases and given the ecosystem enough time to adjust
>> (and provide feedback) we might come to different conclusions.
>>
>> As I've also outlined in the document, _if_ GHC was trivially swappable,
>> companies like IOG would _love_ to try new compilers and report back bugs
>> and regressions. As it is today, we can't. Making a large live codebase
>> compatible with 9.8 is a multiple weeks effort. Experimenting with
>> nightlies is technically impossible. _If_ I could setup the built of our
>> software trivial with ghc nightlies, I'd be _happy_ to build the
>> infrastructure out it to provide performance regressions (compilation,
>> runtime, ...) for our codebase and provide the feedback to the GHC team;
>> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
>> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
>> going to see any further releases, so I can spare trying to even forward
>> port my patches to HEAD. Not that I could even test them with head
>> properly, as our source is not accepted by HEAD. Thus I end up writing
>> patches against old stale branches. This to me is a fairly big
>> discouragement from contributing to GHC.
>>
>> Best,
>>  Moritz
>>
>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com> wrote:
>>
>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>
>>> A strong stability guarantee is certainly a valuable goal, but it also
>>> comes with costs, which I'd like to see more clearly articulated. Some
>>> of them include:
>>>
>>>   * Cognitive overhead for users, because of the inability to remove
>>> complexity from the design.
>>>
>>>   * Increasing maintenance burden in the compiler, because of the
>>> additional work needed to implement new features and the inability to
>>> remove complexity from the implementation.
>>>
>>>   * A risk of getting stuck in a local optimum, because moving to a
>>> better design would entail breaking changes.
>>>
>>>   * Discouraging volunteer contributors, who are much less likely to
>>> work on a potentially beneficial change if the process for getting it
>>> approved is too onerous. (I'm worried we're already reaching that point
>>> due to the increasing burden of well-intentioned processes.)
>>>
>>> Ultimately every proposed change has a cost-benefit trade-off, with risk
>>> of breakage being one of the costs. We need to consciously evaluate that
>>> trade-off on a case-by-case basis. Almost all changes might break
>>> something (e.g. by regressing performance, or for Hyrum's Law reasons),
>>> so there needs to be a proportionate assessment of how likely each
>>> change is to be damaging in practice, bearing in mind that such an
>>> assessment is itself costly and limited in scope.
>>>
>>> It seems to me that the GHC team have taken on board lessons regarding
>>> stability of the language, and the extension system already gives quite
>>> a lot of flexibility to evolve the language in a backwards-compatible
>>> way. In my experience, the key stability problems preventing upgrades to
>>> recent GHC releases are:
>>>
>>>   * The cascading effect of breaking changes in one library causing the
>>> need to upgrade libraries which depend upon it. This is primarily under
>>> the control of the CLC and library maintainers, however, not the GHC
>>> team. It would help if base was minimal and reinstallable, but that
>>> isn't a total solution either, because you'd still have to worry about
>>> packages depending on template-haskell or the ghc package itself.
>>>
>>>   * Performance regressions or critical bugs. These tend to be a
>>> significant obstacle to upgrading for smaller commercial users. But
>>> spending more of our limited resources on stability of the language
>>> means fewer resources for resolving these issues.
>>>
>>> There's surely more we can do here, but let's be careful not to pay too
>>> many costs to achieve stability of the *language* alone, when stability
>>> of the *libraries* and *implementation* are both more important and
>>> harder to fix.
>>>
>>> Adam
>>>
>>>
>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>> > Dear GHC SC
>>> >
>>> > To avoid derailing the debate about -Wsevere
>>> > <
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>>> and HasField redesign <
>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>>> I'm starting a new (email for now) thread about stability.
>>> >
>>> > I have tried to articulate what I believe is an evolving consensus in
>>> > this document
>>> > <
>>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>>> >.
>>> >
>>> > If we converge, we'll turn that into a proper PR for the GHC proposal
>>> > process, although it has wider implications than just GHC proposals
>>> and
>>> > we should share with a broader audience.  But let's start with the
>>> > steering committee.
>>> >
>>> > Any views?  You all have edit rights.
>>> >
>>> > I think that the draft covers Moritz's and Julian's goals, at least
>>> that
>>> > was my intention.  I have pasted Moritz's last email below, for
>>> context.
>>> >
>>> > Simon
>>> >
>>> >
>>> > ========= Moritz's last email ============
>>> >
>>> > Now, this is derailing the original discussion a bit, and I'm not sure
>>> > how far we want to take this. But, regarding @Simon Marlow
>>> > <mailto:marlowsd at gmail.com>'s comment
>>> >
>>> >     This is one cultural aspect of our community I'd like to shift: the
>>> >     expectation that it's OK to make breaking changes as long as you
>>> >     warn about
>>> >     them or go through a migration cycle. It just isn't! (and I speak
>>> as
>>> >     someone who used to make lots of changes, I'm now fully
>>> repentant!).
>>> >     That's
>>> >     not to say that we shouldn't ever change anything, but when
>>> >     considering the
>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>>> >     cost, it
>>> >     just defers it.
>>> >
>>> >
>>> > I actually read this as we should stop having breaking changes to
>>> begin
>>> > with. And _if_ we
>>> > do have breaking changes, that deprecation does not change the need to
>>> > actually change
>>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>>> > <mailto:lists at richarde.dev>'s observation, it
>>> > "smears" the cost. The--to me--_much_ bigger implication of
>>> deprecation
>>> > cycles is that we
>>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>>> > _after the fact_. We
>>> > also give them ample time to react. Being by changing their code, or
>>> > raising their concerns.
>>> > Would the Simplified Subsumptions / Deep Subsumptions change
>>> have looked
>>> > differently?
>>> > As such I see deprecation cycles as orthogonal to the question if we
>>> > should have breaking
>>> > changes to begin with.
>>> >
>>> > Thus I believe the following:
>>> >
>>> >     - Do have a deprecation cycle if possible.
>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are
>>> deferred
>>> >     but are as large as ever.
>>> >
>>> >
>>> > should be upgraded to:
>>> > - Preferably _no_ breaking changes.
>>> > - If breaking changes, then with a deprecation cycle, unless
>>> technically
>>> > infeasible.
>>> > - An understanding that any breaking change incurs significant costs.
>>> >
>>> > Ocaml recently added multicore support, and they put tremendous effort
>>> > into making
>>> > sure it keeps backwards compatibility:
>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>> >
>>> >     PS: we should also agree that a "stable" extension should not
>>> >     require dependencies on ghc-experimental.  To become stable, any
>>> >     library support for an extension must move into `base`.
>>> >
>>> >
>>> > This seems like a good idea, however I still remain that
>>> _experimental_
>>> > features should not be on-by-default in a stable compiler. Yes,
>>> ideally
>>> > I'd not even see them in a stable compiler, but I know this view is
>>> > contentious. The use of `ghc-experimental` should therefore be guarded
>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
>>> > experimental features.
>>> >
>>>
>>> --
>>> Adam Gundry, Haskell Consultant
>>> Well-Typed LLP, https://www.well-typed.com/
>>>
>>> Registered in England & Wales, OC335890
>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>
>>> _______________________________________________
>>> 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/20230928/08baa419/attachment-0001.html>

From marlowsd at gmail.com  Thu Sep 28 07:12:10 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 28 Sep 2023 08:12:10 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
	accept)
Message-ID: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>

Dear committee,

#526 proposes a new extension ApplicativeComprehensions (implying
MonadComprehensions). It would provide the equivalent of the current
ApplicativeDo desugaring for do-expressions to list comprehensions.

   - Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/526>
   - Rendered
   <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst>

The extension itself is relatively uncontroversial, but there are some
unresolved quirks in the original ApplicativeDo extension which made us
uneasy about extending it. However, after various discussions I'm going to
propose accepting this proposal in its current state.  Rationale:

   - It doesn't make things worse, and the implementation isn't likely to
   add significant complexity.
   - It retains consistency between ApplicativeDo and
   ApplicativeComprehensions (in contrast to the idea of making
   ApplicativeComprehensions perform a simpler desugaring, which came up
   during the discussion)
   - A future proposal can add a simpler version of the desugaring for both
   extensions later.


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

From simon.peytonjones at gmail.com  Thu Sep 28 11:29:42 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 28 Sep 2023 12:29:42 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
Message-ID: <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>

>
> Should we have a document (or better spreadsheet?) with a bullet point for
> each experimental feature to be considered? I believe we need to take into
> account that we can’t end up classifying most of todays Haskell programs
> unstable. As such I’d like to propose that we’d add to each features a
> counter for how much of hackage (as a proxy for real world usage) uses the
> specific feature.
>

I think that would be a helpful way to "ground" the discussion a bit more.
(The spreadsheet should also give a preliminary classification of
extensions, at least into stable/experimental.)

I'm running out of capacity to drive this debate, useful though it is.
Does anyone else feel able to drive some of the legwork?

So far this is all informal committee discussion.  The next step would be a
GHC Proposal inviting broader feedback from the community.  I'm just hoping
that by debugging it between ourselves we can side-step some unproductive
discussions in that bigger context.

I believe we need to take into account that we can’t end up classifying
> most of todays Haskell programs unstable
>

There is a tension here.  If we say something is "stable" then we have to
be super-careful about changing it.  (That's the whole point.)  And yet if
the feature (like INCOHERENT) is a flaky "you are on your own"
unsafePerformIO-like feature, I am axious about tying ourselves into an
inability to change the behaviour of corner cases.  I'm not sure how to
resolve this tension.

Simon



On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> I think we are moving in the right direction! I do see however the tension
> rising on (2). And without being clear about (2), I don’t think we can
> properly agree on (1). We can agree on (1) in principle, but we need to
> clarify what we consider unstable/experimental, as a precondition to have
> finale agreement on (1). Otherwise people might agree to (1), only to be
> surprised by (2). For (3), I’d be happy to try to get my employer to
> provide resources for the implementation of —std=experimental.
>
> Thusly I believe we should start to build a list of features we consider
> sufficiently experimental that they should preclude an existing Haskell
> program from being considered stable. This list for me contains so far:
>
> - Linear Types
> - Dependent Haskell
>
> Adam pointed out experimental backend and non-tire-1 platforms. I tend to
> agree with this, but see this distinctly separate from the language
> stability (outside of backend specific language extensions, e.g. JSFFI).
>
> Platforms/backends may be experimental but those are (safe for specific
> lang exts) orthogonal to the Haskell code the compiler accepts.
>
> Should we have a document (or better spreadsheet?) with a bullet point for
> each experimental feature to be considered? I believe we need to take into
> account that we can’t end up classifying most of todays Haskell programs
> unstable. As such I’d like to propose that we’d add to each features a
> counter for how much of hackage (as a proxy for real world usage) uses the
> specific feature.
>
> Best,
>  Moritz
>
> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> it's essential that we continue to have these discussions to ensure we're
>>> making the best decisions for the project and our community.
>>>
>>
>> Yes exactly!  Its tricky and nuanced; hence trying to articulate
>> something in a concrete doc, so we are all on the same page (literally!).
>>
>> However, deprecation cycles don't mean we're averse to major changes. It
>>> means we introduce them responsibly. When we believe a superior design is
>>> possible, we can start a deprecation process to transition towards it.
>>>
>>
>> I have tried to make this explicit in Section 4.   See what you think.
>>
>> I think there are three phases
>>
>>    1. Agree this document.  Is it what we want.
>>    2. Categorise extensions into stable/experimental, and identify
>>    experimental language features.
>>    3. Implement --std=experimental (Section 6).
>>
>> (1) is what we are doing now.  (2) will be some work, done by us.  (3) is
>> a larger task: it will require significant work to implement, and may
>> impose unwelcome churn of its own.  But that should not stop us doing (1)
>> and (2).
>>
>> Simon
>>
>>    -
>>
>>
>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> Dear Adam,
>>>
>>> Thank you for your thoughtful feedback. I understand your reservations,
>>> and it's essential that we continue to have these discussions to ensure
>>> we're making the best decisions for the project and our community. Let me
>>> address each of your points in turn:
>>> - Cognitive Overhead for Users:
>>> I understand the concern about cognitive overhead due to the inability
>>> to remove complexity. However, our primary intention is to ensure a gradual
>>> transition for our users rather than abrupt shifts. Introducing changes via
>>> deprecation cycles allows users to adjust to modifications over time,
>>> reducing the immediate cognitive load. It's a balance between stability and
>>> simplicity, and I believe this approach allows us still to reduce
>>> complexity.
>>>
>>> - Maintenance Burden in the Compiler:
>>> Maintaining backward compatibility does indeed introduce some overhead.
>>> Still, it also encourages a more disciplined and considered approach to
>>> changes. With our deprecation cycles in place, it's not that we never
>>> remove complexity; rather, we do it in a way that provides ample time for
>>> adjustments. This benefits both the development team and the community.
>>>
>>> - Risk of Local Optimum:
>>> This is a valid concern. However, deprecation cycles don't mean we're
>>> averse to major changes. It means we introduce them responsibly. When we
>>> believe a superior design is possible, we can start a deprecation process
>>> to transition towards it. The flexibility and duration of our deprecation
>>> cycles can be tailored depending on the severity of the breaking change.
>>>
>>> - Discouraging Volunteer Contributors:
>>> I understand that lengthy approval processes can be off-putting. But
>>> it's crucial to note that a rigorous process ensures the consistency and
>>> reliability of our project. We always welcome and value contributions.
>>> Moreover, I believe this stability policy will provide us with clear
>>> guardrails on how changes can be contributed.
>>>
>>> I will not disagree on the costs. I do believe though that the costs for
>>> _breaking_ changes in the compiler ought to be borne by the people making
>>> the change, instead of those who use the compiler (and may not even benefit
>>> of those changes that caused breakage). I also see the team maintaining GHC
>>> as the one to enforce this; they are the ones who cut the releases. The
>>> fact that we may have breaking changes due to _bugs_ is covered explicitly
>>> in the stability policy document.
>>>
>>> With my CLC hat on, I have been focusing on the same stability
>>> guidelines as well (if it breaks existing code, I have been against those
>>> changes without deprecation policies). The issues with the
>>> template-haskell, and ghc library are noted. For the ghc library the
>>> question will remain if we intent to provide a stable api to the compiler
>>> or not. I believe many tools would like to have one, and if we relegate
>>> anything unstable to ghc-experimental this might be achieved. For
>>> template-haskell this is a bigger concern. Maybe we can collectively come
>>> up with a solution that would allow us to provide a more insulated template
>>> haskell interface from the compiler.
>>>
>>> However for template-haskell we might also need to look at what exactly
>>> caused those breaking changes in the past.
>>>
>>> What this document outlines (in my understanding) is that any
>>> experimental feature development can _only_ be visible behind
>>> --std=experimental, and the dependency of ghc-experimental. Unless those
>>> are given, the compiler should accept existing programs. This should allow
>>> us enough room to innovate (everyone is always free to opt-in to bleeding
>>> edge features with --std=experimental).  I also believe that most of what
>>> we have today will need to be treated as non-experimental simply because we
>>> did not have that mechanism before. We don't want to break existing
>>> programs as much as possible, thus relegating existing features into
>>> --std=experimental (except for some fairly clear ones: e.g. Dependent
>>> Haskell, and Linear Types?) is not really possible. What we can however do
>>> is start deprecation phases for a few versions, moving features we consider
>>> highly experimental (or maybe even bad) into `--std=experimental`. Just by
>>> having deprecation phases and given the ecosystem enough time to adjust
>>> (and provide feedback) we might come to different conclusions.
>>>
>>> As I've also outlined in the document, _if_ GHC was trivially swappable,
>>> companies like IOG would _love_ to try new compilers and report back bugs
>>> and regressions. As it is today, we can't. Making a large live codebase
>>> compatible with 9.8 is a multiple weeks effort. Experimenting with
>>> nightlies is technically impossible. _If_ I could setup the built of our
>>> software trivial with ghc nightlies, I'd be _happy_ to build the
>>> infrastructure out it to provide performance regressions (compilation,
>>> runtime, ...) for our codebase and provide the feedback to the GHC team;
>>> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
>>> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
>>> going to see any further releases, so I can spare trying to even forward
>>> port my patches to HEAD. Not that I could even test them with head
>>> properly, as our source is not accepted by HEAD. Thus I end up writing
>>> patches against old stale branches. This to me is a fairly big
>>> discouragement from contributing to GHC.
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com> wrote:
>>>
>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>
>>>> A strong stability guarantee is certainly a valuable goal, but it also
>>>> comes with costs, which I'd like to see more clearly articulated. Some
>>>> of them include:
>>>>
>>>>   * Cognitive overhead for users, because of the inability to remove
>>>> complexity from the design.
>>>>
>>>>   * Increasing maintenance burden in the compiler, because of the
>>>> additional work needed to implement new features and the inability to
>>>> remove complexity from the implementation.
>>>>
>>>>   * A risk of getting stuck in a local optimum, because moving to a
>>>> better design would entail breaking changes.
>>>>
>>>>   * Discouraging volunteer contributors, who are much less likely to
>>>> work on a potentially beneficial change if the process for getting it
>>>> approved is too onerous. (I'm worried we're already reaching that point
>>>> due to the increasing burden of well-intentioned processes.)
>>>>
>>>> Ultimately every proposed change has a cost-benefit trade-off, with
>>>> risk
>>>> of breakage being one of the costs. We need to consciously evaluate
>>>> that
>>>> trade-off on a case-by-case basis. Almost all changes might break
>>>> something (e.g. by regressing performance, or for Hyrum's Law reasons),
>>>> so there needs to be a proportionate assessment of how likely each
>>>> change is to be damaging in practice, bearing in mind that such an
>>>> assessment is itself costly and limited in scope.
>>>>
>>>> It seems to me that the GHC team have taken on board lessons regarding
>>>> stability of the language, and the extension system already gives quite
>>>> a lot of flexibility to evolve the language in a backwards-compatible
>>>> way. In my experience, the key stability problems preventing upgrades
>>>> to
>>>> recent GHC releases are:
>>>>
>>>>   * The cascading effect of breaking changes in one library causing the
>>>> need to upgrade libraries which depend upon it. This is primarily under
>>>> the control of the CLC and library maintainers, however, not the GHC
>>>> team. It would help if base was minimal and reinstallable, but that
>>>> isn't a total solution either, because you'd still have to worry about
>>>> packages depending on template-haskell or the ghc package itself.
>>>>
>>>>   * Performance regressions or critical bugs. These tend to be a
>>>> significant obstacle to upgrading for smaller commercial users. But
>>>> spending more of our limited resources on stability of the language
>>>> means fewer resources for resolving these issues.
>>>>
>>>> There's surely more we can do here, but let's be careful not to pay too
>>>> many costs to achieve stability of the *language* alone, when stability
>>>> of the *libraries* and *implementation* are both more important and
>>>> harder to fix.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>> > Dear GHC SC
>>>> >
>>>> > To avoid derailing the debate about -Wsevere
>>>> > <
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>>>> and HasField redesign <
>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>>>> I'm starting a new (email for now) thread about stability.
>>>> >
>>>> > I have tried to articulate what I believe is an evolving consensus in
>>>> > this document
>>>> > <
>>>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>>>> >.
>>>> >
>>>> > If we converge, we'll turn that into a proper PR for the GHC proposal
>>>> > process, although it has wider implications than just GHC proposals
>>>> and
>>>> > we should share with a broader audience.  But let's start with the
>>>> > steering committee.
>>>> >
>>>> > Any views?  You all have edit rights.
>>>> >
>>>> > I think that the draft covers Moritz's and Julian's goals, at least
>>>> that
>>>> > was my intention.  I have pasted Moritz's last email below, for
>>>> context.
>>>> >
>>>> > Simon
>>>> >
>>>> >
>>>> > ========= Moritz's last email ============
>>>> >
>>>> > Now, this is derailing the original discussion a bit, and I'm not
>>>> sure
>>>> > how far we want to take this. But, regarding @Simon Marlow
>>>> > <mailto:marlowsd at gmail.com>'s comment
>>>> >
>>>> >     This is one cultural aspect of our community I'd like to shift:
>>>> the
>>>> >     expectation that it's OK to make breaking changes as long as you
>>>> >     warn about
>>>> >     them or go through a migration cycle. It just isn't! (and I speak
>>>> as
>>>> >     someone who used to make lots of changes, I'm now fully
>>>> repentant!).
>>>> >     That's
>>>> >     not to say that we shouldn't ever change anything, but when
>>>> >     considering the
>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>>>> >     cost, it
>>>> >     just defers it.
>>>> >
>>>> >
>>>> > I actually read this as we should stop having breaking changes to
>>>> begin
>>>> > with. And _if_ we
>>>> > do have breaking changes, that deprecation does not change the need
>>>> to
>>>> > actually change
>>>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>>>> > <mailto:lists at richarde.dev>'s observation, it
>>>> > "smears" the cost. The--to me--_much_ bigger implication of
>>>> deprecation
>>>> > cycles is that we
>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>>>> > _after the fact_. We
>>>> > also give them ample time to react. Being by changing their code, or
>>>> > raising their concerns.
>>>> > Would the Simplified Subsumptions / Deep Subsumptions change
>>>> have looked
>>>> > differently?
>>>> > As such I see deprecation cycles as orthogonal to the question if we
>>>> > should have breaking
>>>> > changes to begin with.
>>>> >
>>>> > Thus I believe the following:
>>>> >
>>>> >     - Do have a deprecation cycle if possible.
>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are
>>>> deferred
>>>> >     but are as large as ever.
>>>> >
>>>> >
>>>> > should be upgraded to:
>>>> > - Preferably _no_ breaking changes.
>>>> > - If breaking changes, then with a deprecation cycle, unless
>>>> technically
>>>> > infeasible.
>>>> > - An understanding that any breaking change incurs significant costs.
>>>> >
>>>> > Ocaml recently added multicore support, and they put tremendous
>>>> effort
>>>> > into making
>>>> > sure it keeps backwards compatibility:
>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>>> >
>>>> >     PS: we should also agree that a "stable" extension should not
>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>> >     library support for an extension must move into `base`.
>>>> >
>>>> >
>>>> > This seems like a good idea, however I still remain that
>>>> _experimental_
>>>> > features should not be on-by-default in a stable compiler. Yes,
>>>> ideally
>>>> > I'd not even see them in a stable compiler, but I know this view is
>>>> > contentious. The use of `ghc-experimental` should therefore be
>>>> guarded
>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to
>>>> > experimental features.
>>>> >
>>>>
>>>> --
>>>> Adam Gundry, Haskell Consultant
>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>
>>>> Registered in England & Wales, OC335890
>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>
>>>> _______________________________________________
>>>> 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/20230928/4e97cc7c/attachment-0001.html>

From moritz.angermann at gmail.com  Thu Sep 28 12:39:09 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 28 Sep 2023 20:39:09 +0800
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
Message-ID: <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>

Simon,

Thank you for bringing us this far. I'd be happy to step up to drive this
further.

I will say that I do see the tension you see as well. And I do believe if
we come to a conclusion on this stability policy that it will
make GHC development more rigorous, which I think is a good thing for all
of us, not just the consumers of the compiler. I think
we need to stay mindful that we can still freely experiment on the
--std=experimental (or however that flag ends up being named)
side. I see this whole discussion as leading us towards the
language research reactor side of GHC being primarily confined behind
--std=experimental, and the stability seeking (commercial application?) on
the other side.

I do not yet see how we can end up with the inability to change. We will
just have a clearer process for _breaking_ changes. This
does absolutely not mean we have to end up in a local optimum, or that we
can not change. We can!

Unless someone speaks up who does _not_ want me to drive, this, I'm happy
to start driving this discussion (including writing the
proposals, starting next week).

Best,
 Moritz

On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Should we have a document (or better spreadsheet?) with a bullet point for
>> each experimental feature to be considered? I believe we need to take into
>> account that we can’t end up classifying most of todays Haskell programs
>> unstable. As such I’d like to propose that we’d add to each features a
>> counter for how much of hackage (as a proxy for real world usage) uses the
>> specific feature.
>>
>
> I think that would be a helpful way to "ground" the discussion a bit
> more.  (The spreadsheet should also give a preliminary classification of
> extensions, at least into stable/experimental.)
>
> I'm running out of capacity to drive this debate, useful though it is.
> Does anyone else feel able to drive some of the legwork?
>
> So far this is all informal committee discussion.  The next step would be
> a GHC Proposal inviting broader feedback from the community.  I'm just
> hoping that by debugging it between ourselves we can side-step some
> unproductive discussions in that bigger context.
>
> I believe we need to take into account that we can’t end up classifying
>> most of todays Haskell programs unstable
>>
>
> There is a tension here.  If we say something is "stable" then we have to
> be super-careful about changing it.  (That's the whole point.)  And yet if
> the feature (like INCOHERENT) is a flaky "you are on your own"
> unsafePerformIO-like feature, I am axious about tying ourselves into an
> inability to change the behaviour of corner cases.  I'm not sure how to
> resolve this tension.
>
> Simon
>
>
>
> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <
> moritz.angermann at gmail.com> wrote:
>
>> I think we are moving in the right direction! I do see however the
>> tension rising on (2). And without being clear about (2), I don’t think we
>> can properly agree on (1). We can agree on (1) in principle, but we need to
>> clarify what we consider unstable/experimental, as a precondition to have
>> finale agreement on (1). Otherwise people might agree to (1), only to be
>> surprised by (2). For (3), I’d be happy to try to get my employer to
>> provide resources for the implementation of —std=experimental.
>>
>> Thusly I believe we should start to build a list of features we consider
>> sufficiently experimental that they should preclude an existing Haskell
>> program from being considered stable. This list for me contains so far:
>>
>> - Linear Types
>> - Dependent Haskell
>>
>> Adam pointed out experimental backend and non-tire-1 platforms. I tend to
>> agree with this, but see this distinctly separate from the language
>> stability (outside of backend specific language extensions, e.g. JSFFI).
>>
>> Platforms/backends may be experimental but those are (safe for specific
>> lang exts) orthogonal to the Haskell code the compiler accepts.
>>
>> Should we have a document (or better spreadsheet?) with a bullet point
>> for each experimental feature to be considered? I believe we need to take
>> into account that we can’t end up classifying most of todays Haskell
>> programs unstable. As such I’d like to propose that we’d add to each
>> features a counter for how much of hackage (as a proxy for real world
>> usage) uses the specific feature.
>>
>> Best,
>>  Moritz
>>
>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
>> simon.peytonjones at gmail.com> wrote:
>>
>>> it's essential that we continue to have these discussions to ensure
>>>> we're making the best decisions for the project and our community.
>>>>
>>>
>>> Yes exactly!  Its tricky and nuanced; hence trying to articulate
>>> something in a concrete doc, so we are all on the same page (literally!).
>>>
>>> However, deprecation cycles don't mean we're averse to major changes. It
>>>> means we introduce them responsibly. When we believe a superior design is
>>>> possible, we can start a deprecation process to transition towards it.
>>>>
>>>
>>> I have tried to make this explicit in Section 4.   See what you think.
>>>
>>> I think there are three phases
>>>
>>>    1. Agree this document.  Is it what we want.
>>>    2. Categorise extensions into stable/experimental, and identify
>>>    experimental language features.
>>>    3. Implement --std=experimental (Section 6).
>>>
>>> (1) is what we are doing now.  (2) will be some work, done by us.  (3)
>>> is a larger task: it will require significant work to implement, and may
>>> impose unwelcome churn of its own.  But that should not stop us doing (1)
>>> and (2).
>>>
>>> Simon
>>>
>>>    -
>>>
>>>
>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
>>> moritz.angermann at gmail.com> wrote:
>>>
>>>> Dear Adam,
>>>>
>>>> Thank you for your thoughtful feedback. I understand your reservations,
>>>> and it's essential that we continue to have these discussions to ensure
>>>> we're making the best decisions for the project and our community. Let me
>>>> address each of your points in turn:
>>>> - Cognitive Overhead for Users:
>>>> I understand the concern about cognitive overhead due to the inability
>>>> to remove complexity. However, our primary intention is to ensure a gradual
>>>> transition for our users rather than abrupt shifts. Introducing changes via
>>>> deprecation cycles allows users to adjust to modifications over time,
>>>> reducing the immediate cognitive load. It's a balance between stability and
>>>> simplicity, and I believe this approach allows us still to reduce
>>>> complexity.
>>>>
>>>> - Maintenance Burden in the Compiler:
>>>> Maintaining backward compatibility does indeed introduce some overhead.
>>>> Still, it also encourages a more disciplined and considered approach to
>>>> changes. With our deprecation cycles in place, it's not that we never
>>>> remove complexity; rather, we do it in a way that provides ample time for
>>>> adjustments. This benefits both the development team and the community.
>>>>
>>>> - Risk of Local Optimum:
>>>> This is a valid concern. However, deprecation cycles don't mean we're
>>>> averse to major changes. It means we introduce them responsibly. When we
>>>> believe a superior design is possible, we can start a deprecation process
>>>> to transition towards it. The flexibility and duration of our deprecation
>>>> cycles can be tailored depending on the severity of the breaking change.
>>>>
>>>> - Discouraging Volunteer Contributors:
>>>> I understand that lengthy approval processes can be off-putting. But
>>>> it's crucial to note that a rigorous process ensures the consistency and
>>>> reliability of our project. We always welcome and value contributions.
>>>> Moreover, I believe this stability policy will provide us with clear
>>>> guardrails on how changes can be contributed.
>>>>
>>>> I will not disagree on the costs. I do believe though that the costs
>>>> for _breaking_ changes in the compiler ought to be borne by the people
>>>> making the change, instead of those who use the compiler (and may not even
>>>> benefit of those changes that caused breakage). I also see the team
>>>> maintaining GHC as the one to enforce this; they are the ones who cut the
>>>> releases. The fact that we may have breaking changes due to _bugs_ is
>>>> covered explicitly in the stability policy document.
>>>>
>>>> With my CLC hat on, I have been focusing on the same stability
>>>> guidelines as well (if it breaks existing code, I have been against those
>>>> changes without deprecation policies). The issues with the
>>>> template-haskell, and ghc library are noted. For the ghc library the
>>>> question will remain if we intent to provide a stable api to the compiler
>>>> or not. I believe many tools would like to have one, and if we relegate
>>>> anything unstable to ghc-experimental this might be achieved. For
>>>> template-haskell this is a bigger concern. Maybe we can collectively come
>>>> up with a solution that would allow us to provide a more insulated template
>>>> haskell interface from the compiler.
>>>>
>>>> However for template-haskell we might also need to look at what exactly
>>>> caused those breaking changes in the past.
>>>>
>>>> What this document outlines (in my understanding) is that any
>>>> experimental feature development can _only_ be visible behind
>>>> --std=experimental, and the dependency of ghc-experimental. Unless those
>>>> are given, the compiler should accept existing programs. This should allow
>>>> us enough room to innovate (everyone is always free to opt-in to bleeding
>>>> edge features with --std=experimental).  I also believe that most of what
>>>> we have today will need to be treated as non-experimental simply because we
>>>> did not have that mechanism before. We don't want to break existing
>>>> programs as much as possible, thus relegating existing features into
>>>> --std=experimental (except for some fairly clear ones: e.g. Dependent
>>>> Haskell, and Linear Types?) is not really possible. What we can however do
>>>> is start deprecation phases for a few versions, moving features we consider
>>>> highly experimental (or maybe even bad) into `--std=experimental`. Just by
>>>> having deprecation phases and given the ecosystem enough time to adjust
>>>> (and provide feedback) we might come to different conclusions.
>>>>
>>>> As I've also outlined in the document, _if_ GHC was trivially
>>>> swappable, companies like IOG would _love_ to try new compilers and report
>>>> back bugs and regressions. As it is today, we can't. Making a large live
>>>> codebase compatible with 9.8 is a multiple weeks effort. Experimenting with
>>>> nightlies is technically impossible. _If_ I could setup the built of our
>>>> software trivial with ghc nightlies, I'd be _happy_ to build the
>>>> infrastructure out it to provide performance regressions (compilation,
>>>> runtime, ...) for our codebase and provide the feedback to the GHC team;
>>>> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
>>>> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
>>>> going to see any further releases, so I can spare trying to even forward
>>>> port my patches to HEAD. Not that I could even test them with head
>>>> properly, as our source is not accepted by HEAD. Thus I end up writing
>>>> patches against old stale branches. This to me is a fairly big
>>>> discouragement from contributing to GHC.
>>>>
>>>> Best,
>>>>  Moritz
>>>>
>>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com> wrote:
>>>>
>>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>>
>>>>> A strong stability guarantee is certainly a valuable goal, but it also
>>>>> comes with costs, which I'd like to see more clearly articulated. Some
>>>>> of them include:
>>>>>
>>>>>   * Cognitive overhead for users, because of the inability to remove
>>>>> complexity from the design.
>>>>>
>>>>>   * Increasing maintenance burden in the compiler, because of the
>>>>> additional work needed to implement new features and the inability to
>>>>> remove complexity from the implementation.
>>>>>
>>>>>   * A risk of getting stuck in a local optimum, because moving to a
>>>>> better design would entail breaking changes.
>>>>>
>>>>>   * Discouraging volunteer contributors, who are much less likely to
>>>>> work on a potentially beneficial change if the process for getting it
>>>>> approved is too onerous. (I'm worried we're already reaching that
>>>>> point
>>>>> due to the increasing burden of well-intentioned processes.)
>>>>>
>>>>> Ultimately every proposed change has a cost-benefit trade-off, with
>>>>> risk
>>>>> of breakage being one of the costs. We need to consciously evaluate
>>>>> that
>>>>> trade-off on a case-by-case basis. Almost all changes might break
>>>>> something (e.g. by regressing performance, or for Hyrum's Law
>>>>> reasons),
>>>>> so there needs to be a proportionate assessment of how likely each
>>>>> change is to be damaging in practice, bearing in mind that such an
>>>>> assessment is itself costly and limited in scope.
>>>>>
>>>>> It seems to me that the GHC team have taken on board lessons regarding
>>>>> stability of the language, and the extension system already gives
>>>>> quite
>>>>> a lot of flexibility to evolve the language in a backwards-compatible
>>>>> way. In my experience, the key stability problems preventing upgrades
>>>>> to
>>>>> recent GHC releases are:
>>>>>
>>>>>   * The cascading effect of breaking changes in one library causing
>>>>> the
>>>>> need to upgrade libraries which depend upon it. This is primarily
>>>>> under
>>>>> the control of the CLC and library maintainers, however, not the GHC
>>>>> team. It would help if base was minimal and reinstallable, but that
>>>>> isn't a total solution either, because you'd still have to worry about
>>>>> packages depending on template-haskell or the ghc package itself.
>>>>>
>>>>>   * Performance regressions or critical bugs. These tend to be a
>>>>> significant obstacle to upgrading for smaller commercial users. But
>>>>> spending more of our limited resources on stability of the language
>>>>> means fewer resources for resolving these issues.
>>>>>
>>>>> There's surely more we can do here, but let's be careful not to pay
>>>>> too
>>>>> many costs to achieve stability of the *language* alone, when
>>>>> stability
>>>>> of the *libraries* and *implementation* are both more important and
>>>>> harder to fix.
>>>>>
>>>>> Adam
>>>>>
>>>>>
>>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>>> > Dear GHC SC
>>>>> >
>>>>> > To avoid derailing the debate about -Wsevere
>>>>> > <
>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>>>>> and HasField redesign <
>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>>>>> I'm starting a new (email for now) thread about stability.
>>>>> >
>>>>> > I have tried to articulate what I believe is an evolving consensus
>>>>> in
>>>>> > this document
>>>>> > <
>>>>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>>>>> >.
>>>>> >
>>>>> > If we converge, we'll turn that into a proper PR for the GHC
>>>>> proposal
>>>>> > process, although it has wider implications than just GHC proposals
>>>>> and
>>>>> > we should share with a broader audience.  But let's start with the
>>>>> > steering committee.
>>>>> >
>>>>> > Any views?  You all have edit rights.
>>>>> >
>>>>> > I think that the draft covers Moritz's and Julian's goals, at least
>>>>> that
>>>>> > was my intention.  I have pasted Moritz's last email below, for
>>>>> context.
>>>>> >
>>>>> > Simon
>>>>> >
>>>>> >
>>>>> > ========= Moritz's last email ============
>>>>> >
>>>>> > Now, this is derailing the original discussion a bit, and I'm not
>>>>> sure
>>>>> > how far we want to take this. But, regarding @Simon Marlow
>>>>> > <mailto:marlowsd at gmail.com>'s comment
>>>>> >
>>>>> >     This is one cultural aspect of our community I'd like to shift:
>>>>> the
>>>>> >     expectation that it's OK to make breaking changes as long as you
>>>>> >     warn about
>>>>> >     them or go through a migration cycle. It just isn't! (and I
>>>>> speak as
>>>>> >     someone who used to make lots of changes, I'm now fully
>>>>> repentant!).
>>>>> >     That's
>>>>> >     not to say that we shouldn't ever change anything, but when
>>>>> >     considering the
>>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>>>>> >     cost, it
>>>>> >     just defers it.
>>>>> >
>>>>> >
>>>>> > I actually read this as we should stop having breaking changes to
>>>>> begin
>>>>> > with. And _if_ we
>>>>> > do have breaking changes, that deprecation does not change the need
>>>>> to
>>>>> > actually change
>>>>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg
>>>>> > <mailto:lists at richarde.dev>'s observation, it
>>>>> > "smears" the cost. The--to me--_much_ bigger implication of
>>>>> deprecation
>>>>> > cycles is that we
>>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>>>>> > _after the fact_. We
>>>>> > also give them ample time to react. Being by changing their code, or
>>>>> > raising their concerns.
>>>>> > Would the Simplified Subsumptions / Deep Subsumptions change
>>>>> have looked
>>>>> > differently?
>>>>> > As such I see deprecation cycles as orthogonal to the question if we
>>>>> > should have breaking
>>>>> > changes to begin with.
>>>>> >
>>>>> > Thus I believe the following:
>>>>> >
>>>>> >     - Do have a deprecation cycle if possible.
>>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are
>>>>> deferred
>>>>> >     but are as large as ever.
>>>>> >
>>>>> >
>>>>> > should be upgraded to:
>>>>> > - Preferably _no_ breaking changes.
>>>>> > - If breaking changes, then with a deprecation cycle, unless
>>>>> technically
>>>>> > infeasible.
>>>>> > - An understanding that any breaking change incurs significant costs.
>>>>> >
>>>>> > Ocaml recently added multicore support, and they put tremendous
>>>>> effort
>>>>> > into making
>>>>> > sure it keeps backwards compatibility:
>>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>>> >
>>>>> >
>>>>> >     PS: we should also agree that a "stable" extension should not
>>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>>> >     library support for an extension must move into `base`.
>>>>> >
>>>>> >
>>>>> > This seems like a good idea, however I still remain that
>>>>> _experimental_
>>>>> > features should not be on-by-default in a stable compiler. Yes,
>>>>> ideally
>>>>> > I'd not even see them in a stable compiler, but I know this view is
>>>>> > contentious. The use of `ghc-experimental` should therefore be
>>>>> guarded
>>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in
>>>>> to
>>>>> > experimental features.
>>>>> >
>>>>>
>>>>> --
>>>>> Adam Gundry, Haskell Consultant
>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>
>>>>> Registered in England & Wales, OC335890
>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20230928/75843030/attachment-0001.html>

From simon.peytonjones at gmail.com  Thu Sep 28 13:15:04 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 28 Sep 2023 14:15:04 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
Message-ID: <CAJKmMz-V6J5U=zvVGRpe3BvM08w5_7LV2wm2BbtFsmNe8oAUTA@mail.gmail.com>

>
> I do not yet see how we can end up with the inability to change. We will
> just have a clearer process for _breaking_ changes. This
>
does absolutely not mean we have to end up in a local optimum, or that we
> can not change. We can
>

Agreed that stable features are not unable to change... it's just that the
bar is higher (that's the intent), so change is more expensive.  E.g.
suppose we want to change some fine point about the semantics of
INCOHERENT.  It might be difficult to have both the old semantics and the
new, and somehow give a deprecation warning.  And INCOHERENT is already
saying "I know that the ice is thin here and I'm signed up to the
consequences".

You are reminding us that if a feature is widely depended on, changing it
imposes real costs on users.  I'm reminding us that making more things
"stable" imposes real costs on GHC's design and implementation team -- on
whom we all rely.  Both concerns are legitimate. We will need to debate
each stable/experimental choice on a case by case basis, informed (among
other things) but how widely used they are.

Simon


On Thu, 28 Sept 2023 at 13:39, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Simon,
>
> Thank you for bringing us this far. I'd be happy to step up to drive this
> further.
>
> I will say that I do see the tension you see as well. And I do believe if
> we come to a conclusion on this stability policy that it will
> make GHC development more rigorous, which I think is a good thing for all
> of us, not just the consumers of the compiler. I think
> we need to stay mindful that we can still freely experiment on the
> --std=experimental (or however that flag ends up being named)
> side. I see this whole discussion as leading us towards the
> language research reactor side of GHC being primarily confined behind
> --std=experimental, and the stability seeking (commercial application?) on
> the other side.
>
> I do not yet see how we can end up with the inability to change. We will
> just have a clearer process for _breaking_ changes. This
> does absolutely not mean we have to end up in a local optimum, or that we
> can not change. We can!
>
> Unless someone speaks up who does _not_ want me to drive, this, I'm happy
> to start driving this discussion (including writing the
> proposals, starting next week).
>
> Best,
>  Moritz
>
> On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Should we have a document (or better spreadsheet?) with a bullet point
>>> for each experimental feature to be considered? I believe we need to take
>>> into account that we can’t end up classifying most of todays Haskell
>>> programs unstable. As such I’d like to propose that we’d add to each
>>> features a counter for how much of hackage (as a proxy for real world
>>> usage) uses the specific feature.
>>>
>>
>> I think that would be a helpful way to "ground" the discussion a bit
>> more.  (The spreadsheet should also give a preliminary classification of
>> extensions, at least into stable/experimental.)
>>
>> I'm running out of capacity to drive this debate, useful though it is.
>> Does anyone else feel able to drive some of the legwork?
>>
>> So far this is all informal committee discussion.  The next step would be
>> a GHC Proposal inviting broader feedback from the community.  I'm just
>> hoping that by debugging it between ourselves we can side-step some
>> unproductive discussions in that bigger context.
>>
>> I believe we need to take into account that we can’t end up classifying
>>> most of todays Haskell programs unstable
>>>
>>
>> There is a tension here.  If we say something is "stable" then we have to
>> be super-careful about changing it.  (That's the whole point.)  And yet if
>> the feature (like INCOHERENT) is a flaky "you are on your own"
>> unsafePerformIO-like feature, I am axious about tying ourselves into an
>> inability to change the behaviour of corner cases.  I'm not sure how to
>> resolve this tension.
>>
>> Simon
>>
>>
>>
>> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> I think we are moving in the right direction! I do see however the
>>> tension rising on (2). And without being clear about (2), I don’t think we
>>> can properly agree on (1). We can agree on (1) in principle, but we need to
>>> clarify what we consider unstable/experimental, as a precondition to have
>>> finale agreement on (1). Otherwise people might agree to (1), only to be
>>> surprised by (2). For (3), I’d be happy to try to get my employer to
>>> provide resources for the implementation of —std=experimental.
>>>
>>> Thusly I believe we should start to build a list of features we consider
>>> sufficiently experimental that they should preclude an existing Haskell
>>> program from being considered stable. This list for me contains so far:
>>>
>>> - Linear Types
>>> - Dependent Haskell
>>>
>>> Adam pointed out experimental backend and non-tire-1 platforms. I tend
>>> to agree with this, but see this distinctly separate from the language
>>> stability (outside of backend specific language extensions, e.g. JSFFI).
>>>
>>> Platforms/backends may be experimental but those are (safe for specific
>>> lang exts) orthogonal to the Haskell code the compiler accepts.
>>>
>>> Should we have a document (or better spreadsheet?) with a bullet point
>>> for each experimental feature to be considered? I believe we need to take
>>> into account that we can’t end up classifying most of todays Haskell
>>> programs unstable. As such I’d like to propose that we’d add to each
>>> features a counter for how much of hackage (as a proxy for real world
>>> usage) uses the specific feature.
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> it's essential that we continue to have these discussions to ensure
>>>>> we're making the best decisions for the project and our community.
>>>>>
>>>>
>>>> Yes exactly!  Its tricky and nuanced; hence trying to articulate
>>>> something in a concrete doc, so we are all on the same page (literally!).
>>>>
>>>> However, deprecation cycles don't mean we're averse to major changes.
>>>>> It means we introduce them responsibly. When we believe a superior design
>>>>> is possible, we can start a deprecation process to transition towards it.
>>>>>
>>>>
>>>> I have tried to make this explicit in Section 4.   See what you think.
>>>>
>>>> I think there are three phases
>>>>
>>>>    1. Agree this document.  Is it what we want.
>>>>    2. Categorise extensions into stable/experimental, and identify
>>>>    experimental language features.
>>>>    3. Implement --std=experimental (Section 6).
>>>>
>>>> (1) is what we are doing now.  (2) will be some work, done by us.  (3)
>>>> is a larger task: it will require significant work to implement, and may
>>>> impose unwelcome churn of its own.  But that should not stop us doing (1)
>>>> and (2).
>>>>
>>>> Simon
>>>>
>>>>    -
>>>>
>>>>
>>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> Dear Adam,
>>>>>
>>>>> Thank you for your thoughtful feedback. I understand your
>>>>> reservations, and it's essential that we continue to have these discussions
>>>>> to ensure we're making the best decisions for the project and our
>>>>> community. Let me address each of your points in turn:
>>>>> - Cognitive Overhead for Users:
>>>>> I understand the concern about cognitive overhead due to the inability
>>>>> to remove complexity. However, our primary intention is to ensure a gradual
>>>>> transition for our users rather than abrupt shifts. Introducing changes via
>>>>> deprecation cycles allows users to adjust to modifications over time,
>>>>> reducing the immediate cognitive load. It's a balance between stability and
>>>>> simplicity, and I believe this approach allows us still to reduce
>>>>> complexity.
>>>>>
>>>>> - Maintenance Burden in the Compiler:
>>>>> Maintaining backward compatibility does indeed introduce some
>>>>> overhead. Still, it also encourages a more disciplined and considered
>>>>> approach to changes. With our deprecation cycles in place, it's not that we
>>>>> never remove complexity; rather, we do it in a way that provides ample time
>>>>> for adjustments. This benefits both the development team and the community.
>>>>>
>>>>> - Risk of Local Optimum:
>>>>> This is a valid concern. However, deprecation cycles don't mean we're
>>>>> averse to major changes. It means we introduce them responsibly. When we
>>>>> believe a superior design is possible, we can start a deprecation process
>>>>> to transition towards it. The flexibility and duration of our deprecation
>>>>> cycles can be tailored depending on the severity of the breaking change.
>>>>>
>>>>> - Discouraging Volunteer Contributors:
>>>>> I understand that lengthy approval processes can be off-putting. But
>>>>> it's crucial to note that a rigorous process ensures the consistency and
>>>>> reliability of our project. We always welcome and value contributions.
>>>>> Moreover, I believe this stability policy will provide us with clear
>>>>> guardrails on how changes can be contributed.
>>>>>
>>>>> I will not disagree on the costs. I do believe though that the costs
>>>>> for _breaking_ changes in the compiler ought to be borne by the people
>>>>> making the change, instead of those who use the compiler (and may not even
>>>>> benefit of those changes that caused breakage). I also see the team
>>>>> maintaining GHC as the one to enforce this; they are the ones who cut the
>>>>> releases. The fact that we may have breaking changes due to _bugs_ is
>>>>> covered explicitly in the stability policy document.
>>>>>
>>>>> With my CLC hat on, I have been focusing on the same stability
>>>>> guidelines as well (if it breaks existing code, I have been against those
>>>>> changes without deprecation policies). The issues with the
>>>>> template-haskell, and ghc library are noted. For the ghc library the
>>>>> question will remain if we intent to provide a stable api to the compiler
>>>>> or not. I believe many tools would like to have one, and if we relegate
>>>>> anything unstable to ghc-experimental this might be achieved. For
>>>>> template-haskell this is a bigger concern. Maybe we can collectively come
>>>>> up with a solution that would allow us to provide a more insulated template
>>>>> haskell interface from the compiler.
>>>>>
>>>>> However for template-haskell we might also need to look at what
>>>>> exactly caused those breaking changes in the past.
>>>>>
>>>>> What this document outlines (in my understanding) is that any
>>>>> experimental feature development can _only_ be visible behind
>>>>> --std=experimental, and the dependency of ghc-experimental. Unless those
>>>>> are given, the compiler should accept existing programs. This should allow
>>>>> us enough room to innovate (everyone is always free to opt-in to bleeding
>>>>> edge features with --std=experimental).  I also believe that most of what
>>>>> we have today will need to be treated as non-experimental simply because we
>>>>> did not have that mechanism before. We don't want to break existing
>>>>> programs as much as possible, thus relegating existing features into
>>>>> --std=experimental (except for some fairly clear ones: e.g. Dependent
>>>>> Haskell, and Linear Types?) is not really possible. What we can however do
>>>>> is start deprecation phases for a few versions, moving features we consider
>>>>> highly experimental (or maybe even bad) into `--std=experimental`. Just by
>>>>> having deprecation phases and given the ecosystem enough time to adjust
>>>>> (and provide feedback) we might come to different conclusions.
>>>>>
>>>>> As I've also outlined in the document, _if_ GHC was trivially
>>>>> swappable, companies like IOG would _love_ to try new compilers and report
>>>>> back bugs and regressions. As it is today, we can't. Making a large live
>>>>> codebase compatible with 9.8 is a multiple weeks effort. Experimenting with
>>>>> nightlies is technically impossible. _If_ I could setup the built of our
>>>>> software trivial with ghc nightlies, I'd be _happy_ to build the
>>>>> infrastructure out it to provide performance regressions (compilation,
>>>>> runtime, ...) for our codebase and provide the feedback to the GHC team;
>>>>> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
>>>>> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
>>>>> going to see any further releases, so I can spare trying to even forward
>>>>> port my patches to HEAD. Not that I could even test them with head
>>>>> properly, as our source is not accepted by HEAD. Thus I end up writing
>>>>> patches against old stale branches. This to me is a fairly big
>>>>> discouragement from contributing to GHC.
>>>>>
>>>>> Best,
>>>>>  Moritz
>>>>>
>>>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com>
>>>>> wrote:
>>>>>
>>>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>>>
>>>>>> A strong stability guarantee is certainly a valuable goal, but it
>>>>>> also
>>>>>> comes with costs, which I'd like to see more clearly articulated.
>>>>>> Some
>>>>>> of them include:
>>>>>>
>>>>>>   * Cognitive overhead for users, because of the inability to remove
>>>>>> complexity from the design.
>>>>>>
>>>>>>   * Increasing maintenance burden in the compiler, because of the
>>>>>> additional work needed to implement new features and the inability to
>>>>>> remove complexity from the implementation.
>>>>>>
>>>>>>   * A risk of getting stuck in a local optimum, because moving to a
>>>>>> better design would entail breaking changes.
>>>>>>
>>>>>>   * Discouraging volunteer contributors, who are much less likely to
>>>>>> work on a potentially beneficial change if the process for getting it
>>>>>> approved is too onerous. (I'm worried we're already reaching that
>>>>>> point
>>>>>> due to the increasing burden of well-intentioned processes.)
>>>>>>
>>>>>> Ultimately every proposed change has a cost-benefit trade-off, with
>>>>>> risk
>>>>>> of breakage being one of the costs. We need to consciously evaluate
>>>>>> that
>>>>>> trade-off on a case-by-case basis. Almost all changes might break
>>>>>> something (e.g. by regressing performance, or for Hyrum's Law
>>>>>> reasons),
>>>>>> so there needs to be a proportionate assessment of how likely each
>>>>>> change is to be damaging in practice, bearing in mind that such an
>>>>>> assessment is itself costly and limited in scope.
>>>>>>
>>>>>> It seems to me that the GHC team have taken on board lessons
>>>>>> regarding
>>>>>> stability of the language, and the extension system already gives
>>>>>> quite
>>>>>> a lot of flexibility to evolve the language in a backwards-compatible
>>>>>> way. In my experience, the key stability problems preventing upgrades
>>>>>> to
>>>>>> recent GHC releases are:
>>>>>>
>>>>>>   * The cascading effect of breaking changes in one library causing
>>>>>> the
>>>>>> need to upgrade libraries which depend upon it. This is primarily
>>>>>> under
>>>>>> the control of the CLC and library maintainers, however, not the GHC
>>>>>> team. It would help if base was minimal and reinstallable, but that
>>>>>> isn't a total solution either, because you'd still have to worry
>>>>>> about
>>>>>> packages depending on template-haskell or the ghc package itself.
>>>>>>
>>>>>>   * Performance regressions or critical bugs. These tend to be a
>>>>>> significant obstacle to upgrading for smaller commercial users. But
>>>>>> spending more of our limited resources on stability of the language
>>>>>> means fewer resources for resolving these issues.
>>>>>>
>>>>>> There's surely more we can do here, but let's be careful not to pay
>>>>>> too
>>>>>> many costs to achieve stability of the *language* alone, when
>>>>>> stability
>>>>>> of the *libraries* and *implementation* are both more important and
>>>>>> harder to fix.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>>>> > Dear GHC SC
>>>>>> >
>>>>>> > To avoid derailing the debate about -Wsevere
>>>>>> > <
>>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>>>>>> and HasField redesign <
>>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>>>>>> I'm starting a new (email for now) thread about stability.
>>>>>> >
>>>>>> > I have tried to articulate what I believe is an evolving consensus
>>>>>> in
>>>>>> > this document
>>>>>> > <
>>>>>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>>>>>> >.
>>>>>> >
>>>>>> > If we converge, we'll turn that into a proper PR for the GHC
>>>>>> proposal
>>>>>> > process, although it has wider implications than just GHC proposals
>>>>>> and
>>>>>> > we should share with a broader audience.  But let's start with the
>>>>>> > steering committee.
>>>>>> >
>>>>>> > Any views?  You all have edit rights.
>>>>>> >
>>>>>> > I think that the draft covers Moritz's and Julian's goals, at least
>>>>>> that
>>>>>> > was my intention.  I have pasted Moritz's last email below, for
>>>>>> context.
>>>>>> >
>>>>>> > Simon
>>>>>> >
>>>>>> >
>>>>>> > ========= Moritz's last email ============
>>>>>> >
>>>>>> > Now, this is derailing the original discussion a bit, and I'm not
>>>>>> sure
>>>>>> > how far we want to take this. But, regarding @Simon Marlow
>>>>>> > <mailto:marlowsd at gmail.com>'s comment
>>>>>> >
>>>>>> >     This is one cultural aspect of our community I'd like to shift:
>>>>>> the
>>>>>> >     expectation that it's OK to make breaking changes as long as you
>>>>>> >     warn about
>>>>>> >     them or go through a migration cycle. It just isn't! (and I
>>>>>> speak as
>>>>>> >     someone who used to make lots of changes, I'm now fully
>>>>>> repentant!).
>>>>>> >     That's
>>>>>> >     not to say that we shouldn't ever change anything, but when
>>>>>> >     considering the
>>>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce
>>>>>> the
>>>>>> >     cost, it
>>>>>> >     just defers it.
>>>>>> >
>>>>>> >
>>>>>> > I actually read this as we should stop having breaking changes to
>>>>>> begin
>>>>>> > with. And _if_ we
>>>>>> > do have breaking changes, that deprecation does not change the need
>>>>>> to
>>>>>> > actually change
>>>>>> > code (cost). As outlined in my reply to that, and @Richard
>>>>>> Eisenberg
>>>>>> > <mailto:lists at richarde.dev>'s observation, it
>>>>>> > "smears" the cost. The--to me--_much_ bigger implication of
>>>>>> deprecation
>>>>>> > cycles is that we
>>>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>>>>>> > _after the fact_. We
>>>>>> > also give them ample time to react. Being by changing their code,
>>>>>> or
>>>>>> > raising their concerns.
>>>>>> > Would the Simplified Subsumptions / Deep Subsumptions change
>>>>>> have looked
>>>>>> > differently?
>>>>>> > As such I see deprecation cycles as orthogonal to the question if
>>>>>> we
>>>>>> > should have breaking
>>>>>> > changes to begin with.
>>>>>> >
>>>>>> > Thus I believe the following:
>>>>>> >
>>>>>> >     - Do have a deprecation cycle if possible.
>>>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are
>>>>>> deferred
>>>>>> >     but are as large as ever.
>>>>>> >
>>>>>> >
>>>>>> > should be upgraded to:
>>>>>> > - Preferably _no_ breaking changes.
>>>>>> > - If breaking changes, then with a deprecation cycle, unless
>>>>>> technically
>>>>>> > infeasible.
>>>>>> > - An understanding that any breaking change incurs significant
>>>>>> costs.
>>>>>> >
>>>>>> > Ocaml recently added multicore support, and they put tremendous
>>>>>> effort
>>>>>> > into making
>>>>>> > sure it keeps backwards compatibility:
>>>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>>>> > <
>>>>>> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>>>>> >
>>>>>> >     PS: we should also agree that a "stable" extension should not
>>>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>>>> >     library support for an extension must move into `base`.
>>>>>> >
>>>>>> >
>>>>>> > This seems like a good idea, however I still remain that
>>>>>> _experimental_
>>>>>> > features should not be on-by-default in a stable compiler. Yes,
>>>>>> ideally
>>>>>> > I'd not even see them in a stable compiler, but I know this view is
>>>>>> > contentious. The use of `ghc-experimental` should therefore be
>>>>>> guarded
>>>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in
>>>>>> to
>>>>>> > experimental features.
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Adam Gundry, Haskell Consultant
>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>>
>>>>>> Registered in England & Wales, OC335890
>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20230928/5413b078/attachment-0001.html>

From mail at joachim-breitner.de  Thu Sep 28 18:47:47 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 28 Sep 2023 20:47:47 +0200
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
 accept)
In-Reply-To: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
Message-ID: <1bb49ec5ca5bd9f66c4c2c765cc8ac4fe5b94b19.camel@joachim-breitner.de>

Am Donnerstag, dem 28.09.2023 um 08:12 +0100 schrieb Simon Marlow:
>  I'm going to propose accepting this proposal in its current state. 
> Rationale:
>  * It doesn't make things worse, and the implementation isn't likely
> to add significant complexity.
>  * It retains consistency between ApplicativeDo and
> ApplicativeComprehensions (in contrast to the idea of making
> ApplicativeComprehensions perform a simpler desugaring, which came up
> during the discussion)
>  * A future proposal can add a simpler version of the desugaring for
> both extensions later.

Sounds good to me.
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From adam at well-typed.com  Thu Sep 28 20:29:44 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 28 Sep 2023 21:29:44 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz-V6J5U=zvVGRpe3BvM08w5_7LV2wm2BbtFsmNe8oAUTA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz-V6J5U=zvVGRpe3BvM08w5_7LV2wm2BbtFsmNe8oAUTA@mail.gmail.com>
Message-ID: <d6276d86-0dc6-904b-e61c-5ed2974d0d10@well-typed.com>

I haven't quite been keeping up with all of this thread, but I'm glad to 
see we are making progress and exploring the trade-offs here. Moritz, 
thanks for volunteering to drive this forward and start writing a 
proposal. I'm very happy for you to do so; while we may need to continue 
seeking the right balance between the different concerns, it's a good 
discussion to be having.

I agree with the suggestion to keep the plan for --std=experimental 
(which is about an enforcement mechanism) separate from the policy 
aspects (i.e. what stability guarantees do we offer for which features). 
I can see that having some sort of flag may be helpful, but I'm not yet 
convinced we can reasonably give a simple binary "stable or not" 
classification, and that will become clearer once we more clearly 
categorise features and explore the library stability issue more.

On the template-haskell front, I opened 
https://gitlab.haskell.org/ghc/ghc/-/issues/24021 which explores one 
possible way forward.

Generalising from that ticket, it seems to me that the biggest step we 
could make towards greater stability would be to move away from 
non-reinstallable packages tied to the compiler (like base and 
template-haskell as they stand) towards reinstallable packages. For 
example, if base was a reinstallable package then it could receive a new 
minor version to support a new version of ghc-internal, without breaking 
its clients. The CLC-approved addition of foldl' to Prelude looks set to 
cause a lot of disruption, but if we could use an old major version of 
base with the new GHC, that would be ameliorated significantly. This 
seems like somewhere where more resources could really help.

Finally, in case this is useful, I started talking to the authors of the 
extension stability proposal a little while back about classifying 
extensions, and prepared a very drafty spreadsheet with some initial 
thoughts. Take it with a pinch of salt, but here it is: 
https://docs.google.com/spreadsheets/d/1sRIcNKdflX2ogrx2EF3vKOn0vmv-UEOdladBqtYXdaw/edit#gid=0

Cheers,

Adam


On 28/09/2023 14:15, Simon Peyton Jones wrote:
>     I do not yet see how we can end up with the inability to change. We
>     will just have a clearer process for _breaking_ changes. This
> 
>     does absolutely not mean we have to end up in a local optimum, or
>     that we can not change. We can
> 
> 
> Agreed that stable features are not unable to change... it's just that 
> the bar is higher (that's the intent), so change is more expensive.  
> E.g. suppose we want to change some fine point about the semantics of 
> INCOHERENT.  It might be difficult to have both the old semantics and 
> the new, and somehow give a deprecation warning.  And INCOHERENT is 
> already saying "I know that the ice is thin here and I'm signed up to 
> the consequences".
> 
> You are reminding us that if a feature is widely depended on, changing 
> it imposes real costs on users.  I'm reminding us that making more 
> things "stable" imposes real costs on GHC's design and implementation 
> team -- on whom we all rely.  Both concerns are legitimate. We will need 
> to debate each stable/experimental choice on a case by case basis, 
> informed (among other things) but how widely used they are.
> 
> Simon
> 
> 
> On Thu, 28 Sept 2023 at 13:39, Moritz Angermann 
> <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
> 
>     Simon,
> 
>     Thank you for bringing us this far. I'd be happy to step up to drive
>     this further.
> 
>     I will say that I do see the tension you see as well. And I do
>     believe if we come to a conclusion on this stability policy that it will
>     make GHC development more rigorous, which I think is a good thing
>     for all of us, not just the consumers of the compiler. I think
>     we need to stay mindful that we can still freely experiment on the
>     --std=experimental (or however that flag ends up being named)
>     side. I see this whole discussion as leading us towards the
>     language research reactor side of GHC being primarily confined behind
>     --std=experimental, and the stability seeking (commercial
>     application?) on the other side.
> 
>     I do not yet see how we can end up with the inability to change. We
>     will just have a clearer process for _breaking_ changes. This
>     does absolutely not mean we have to end up in a local optimum, or
>     that we can not change. We can!
> 
>     Unless someone speaks up who does _not_ want me to drive, this, I'm
>     happy to start driving this discussion (including writing the
>     proposals, starting next week).
> 
>     Best,
>       Moritz
> 
>     On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones
>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>     wrote:
> 
>             Should we have a document (or better spreadsheet?) with a
>             bullet point for each experimental feature to be considered?
>             I believe we need to take into account that we can’t end up
>             classifying most of todays Haskell programs unstable. As
>             such I’d like to propose that we’d add to each features a
>             counter for how much of hackage (as a proxy for real world
>             usage) uses the specific feature. 
> 
> 
>         I think that would be a helpful way to "ground" the discussion a
>         bit more.  (The spreadsheet should also give a preliminary
>         classification of extensions, at least into stable/experimental.)
> 
>         I'm running out of capacity to drive this debate, useful though
>         it is.  Does anyone else feel able to drive some of the legwork?
> 
>         So far this is all informal committee discussion.  The next step
>         would be a GHC Proposal inviting broader feedback from the
>         community.  I'm just hoping that by debugging it between
>         ourselves we can side-step some unproductive discussions in that
>         bigger context.
> 
>             I believe we need to take into account that we can’t end up
>             classifying most of todays Haskell programs unstable
> 
> 
>         There is a tension here.  If we say something is "stable" then
>         we have to be super-careful about changing it.  (That's the
>         whole point.)  And yet if the feature (like INCOHERENT) is a
>         flaky "you are on your own" unsafePerformIO-like feature, I am
>         axious about tying ourselves into an inability to change the
>         behaviour of corner cases.  I'm not sure how to resolve this
>         tension.
> 
>         Simon
> 
> 
> 
>         On Thu, 28 Sept 2023 at 02:20, Moritz Angermann
>         <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>>
>         wrote:
> 
>             I think we are moving in the right direction! I do see
>             however the tension rising on (2). And without being clear
>             about (2), I don’t think we can properly agree on (1). We
>             can agree on (1) in principle, but we need to clarify what
>             we consider unstable/experimental, as a precondition to have
>             finale agreement on (1). Otherwise people might agree to
>             (1), only to be surprised by (2). For (3), I’d be happy to
>             try to get my employer to provide resources for the
>             implementation of —std=experimental.
> 
>             Thusly I believe we should start to build a list of features
>             we consider sufficiently experimental that they should
>             preclude an existing Haskell program from being considered
>             stable. This list for me contains so far:
> 
>             - Linear Types
>             - Dependent Haskell
> 
>             Adam pointed out experimental backend and non-tire-1
>             platforms. I tend to agree with this, but see this
>             distinctly separate from the language stability (outside of
>             backend specific language extensions, e.g. JSFFI).
> 
>             Platforms/backends may be experimental but those are (safe
>             for specific lang exts) orthogonal to the Haskell code the
>             compiler accepts.
> 
>             Should we have a document (or better spreadsheet?) with a
>             bullet point for each experimental feature to be considered?
>             I believe we need to take into account that we can’t end up
>             classifying most of todays Haskell programs unstable. As
>             such I’d like to propose that we’d add to each features a
>             counter for how much of hackage (as a proxy for real world
>             usage) uses the specific feature.
> 
>             Best,
>               Moritz
> 
>             On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones
>             <simon.peytonjones at gmail.com
>             <mailto:simon.peytonjones at gmail.com>> wrote:
> 
>                     it's essential that we continue to have these
>                     discussions to ensure we're making the best
>                     decisions for the project and our community.
> 
> 
>                 Yes exactly!  Its tricky and nuanced; hence trying to
>                 articulate something in a concrete doc, so we are all on
>                 the same page (literally!).
> 
>                     However, deprecation cycles don't mean we're averse
>                     to major changes. It means we introduce them
>                     responsibly. When we believe a superior design is
>                     possible, we can start a deprecation process to
>                     transition towards it. 
> 
> 
>                 I have tried to make this explicit in Section 4.   See
>                 what you think.
> 
>                 I think there are three phases
> 
>                  1. Agree this document.  Is it what we want.
>                  2. Categorise extensions into stable/experimental, and
>                     identify experimental language features.
>                  3. Implement --std=experimental (Section 6).
> 
>                 (1) is what we are doing now.  (2) will be some work,
>                 done by us.  (3) is a larger task: it will require
>                 significant work to implement, and may impose unwelcome
>                 churn of its own.  But that should not stop us doing (1)
>                 and (2).
> 
>                 Simon
> 
>                   *
> 
> 
> 
>                 On Wed, 27 Sept 2023 at 10:20, Moritz Angermann
>                 <moritz.angermann at gmail.com
>                 <mailto:moritz.angermann at gmail.com>> wrote:
> 
>                     Dear Adam,
> 
>                     Thank you for your thoughtful feedback. I understand
>                     your reservations, and it's essential that we
>                     continue to have these discussions to ensure we're
>                     making the best decisions for the project and our
>                     community. Let me address each of your points in turn:
> 
>                     - Cognitive Overhead for Users:
>                     I understand the concern about cognitive overhead
>                     due to the inability to remove complexity. However,
>                     our primary intention is to ensure a gradual
>                     transition for our users rather than abrupt shifts.
>                     Introducing changes via deprecation cycles allows
>                     users to adjust to modifications over time, reducing
>                     the immediate cognitive load. It's a balance between
>                     stability and simplicity, and I believe this
>                     approach allows us still to reduce complexity.
> 
>                     - Maintenance Burden in the Compiler:
>                     Maintaining backward compatibility does indeed
>                     introduce some overhead. Still, it also encourages a
>                     more disciplined and considered approach to changes.
>                     With our deprecation cycles in place, it's not that
>                     we never remove complexity; rather, we do it in a
>                     way that provides ample time for adjustments. This
>                     benefits both the development team and the community.
> 
>                     - Risk of Local Optimum:
>                     This is a valid concern. However, deprecation cycles
>                     don't mean we're averse to major changes. It means
>                     we introduce them responsibly. When we believe a
>                     superior design is possible, we can start a
>                     deprecation process to transition towards it. The
>                     flexibility and duration of our deprecation cycles
>                     can be tailored depending on the severity of the
>                     breaking change.
> 
>                     - Discouraging Volunteer Contributors:
>                     I understand that lengthy approval processes can be
>                     off-putting. But it's crucial to note that a
>                     rigorous process ensures the consistency and
>                     reliability of our project. We always welcome and
>                     value contributions. Moreover, I believe this
>                     stability policy will provide us with clear
>                     guardrails on how changes can be contributed.
> 
>                     I will not disagree on the costs. I do believe
>                     though that the costs for _breaking_ changes in the
>                     compiler ought to be borne by the people making the
>                     change, instead of those who use the compiler (and
>                     may not even benefit of those changes that caused
>                     breakage). I also see the team maintaining GHC as
>                     the one to enforce this; they are the ones who cut
>                     the releases. The fact that we may have breaking
>                     changes due to _bugs_ is covered explicitly in the
>                     stability policy document.
> 
>                     With my CLC hat on, I have been focusing on the same
>                     stability guidelines as well (if it breaks existing
>                     code, I have been against those changes without
>                     deprecation policies). The issues with the
>                     template-haskell, and ghc library are noted. For the
>                     ghc library the question will remain if we intent to
>                     provide a stable api to the compiler or not. I
>                     believe many tools would like to have one, and if we
>                     relegate anything unstable to ghc-experimental this
>                     might be achieved. For template-haskell this is a
>                     bigger concern. Maybe we can collectively come up
>                     with a solution that would allow us to provide a
>                     more insulated template haskell interface from the
>                     compiler.
> 
>                     However for template-haskell we might also need to
>                     look at what exactly caused those breaking changes
>                     in the past.
> 
>                     What this document outlines (in my understanding) is
>                     that any experimental feature development can _only_
>                     be visible behind --std=experimental, and the
>                     dependency of ghc-experimental. Unless those are
>                     given, the compiler should accept existing programs.
>                     This should allow us enough room to innovate
>                     (everyone is always free to opt-in to bleeding edge
>                     features with --std=experimental).  I also believe
>                     that most of what we have today will need to be
>                     treated as non-experimental simply because we did
>                     not have that mechanism before. We don't want to
>                     break existing programs as much as possible, thus
>                     relegating existing features into --std=experimental
>                     (except for some fairly clear ones: e.g. Dependent
>                     Haskell, and Linear Types?) is not really possible.
>                     What we can however do is start deprecation phases
>                     for a few versions, moving features we consider
>                     highly experimental (or maybe even bad) into
>                     `--std=experimental`. Just by having deprecation
>                     phases and given the ecosystem enough time to adjust
>                     (and provide feedback) we might come to different
>                     conclusions.
> 
>                     As I've also outlined in the document, _if_ GHC was
>                     trivially swappable, companies like IOG would _love_
>                     to try new compilers and report back bugs and
>                     regressions. As it is today, we can't. Making a
>                     large live codebase compatible with 9.8 is a
>                     multiple weeks effort. Experimenting with nightlies
>                     is technically impossible. _If_ I could setup the
>                     built of our software trivial with ghc nightlies,
>                     I'd be _happy_ to build the infrastructure out it to
>                     provide performance regressions (compilation,
>                     runtime, ...) for our codebase and provide the
>                     feedback to the GHC team; however I can't. And thus
>                     I'm stuck patching and fixing 8.10, and 9.2 today.
>                     9.6 maybe soon, but likely at the point in time
>                     where 9.6 is not going to see any further releases,
>                     so I can spare trying to even forward port my
>                     patches to HEAD. Not that I could even test them
>                     with head properly, as our source is not accepted by
>                     HEAD. Thus I end up writing patches against old
>                     stale branches. This to me is a fairly big
>                     discouragement from contributing to GHC.
> 
>                     Best,
>                       Moritz
> 
>                     On Mon, 25 Sept 2023 at 15:17, Adam Gundry
>                     <adam at well-typed.com <mailto:adam at well-typed.com>>
>                     wrote:
> 
>                         I'm afraid that I'm somewhat sceptical of this
>                         approach.
> 
>                         A strong stability guarantee is certainly a
>                         valuable goal, but it also
>                         comes with costs, which I'd like to see more
>                         clearly articulated. Some
>                         of them include:
> 
>                            * Cognitive overhead for users, because of
>                         the inability to remove
>                         complexity from the design.
> 
>                            * Increasing maintenance burden in the
>                         compiler, because of the
>                         additional work needed to implement new features
>                         and the inability to
>                         remove complexity from the implementation.
> 
>                            * A risk of getting stuck in a local optimum,
>                         because moving to a
>                         better design would entail breaking changes.
> 
>                            * Discouraging volunteer contributors, who
>                         are much less likely to
>                         work on a potentially beneficial change if the
>                         process for getting it
>                         approved is too onerous. (I'm worried we're
>                         already reaching that point
>                         due to the increasing burden of well-intentioned
>                         processes.)
> 
>                         Ultimately every proposed change has a
>                         cost-benefit trade-off, with risk
>                         of breakage being one of the costs. We need to
>                         consciously evaluate that
>                         trade-off on a case-by-case basis. Almost all
>                         changes might break
>                         something (e.g. by regressing performance, or
>                         for Hyrum's Law reasons),
>                         so there needs to be a proportionate assessment
>                         of how likely each
>                         change is to be damaging in practice, bearing in
>                         mind that such an
>                         assessment is itself costly and limited in scope.
> 
>                         It seems to me that the GHC team have taken on
>                         board lessons regarding
>                         stability of the language, and the extension
>                         system already gives quite
>                         a lot of flexibility to evolve the language in a
>                         backwards-compatible
>                         way. In my experience, the key stability
>                         problems preventing upgrades to
>                         recent GHC releases are:
> 
>                            * The cascading effect of breaking changes in
>                         one library causing the
>                         need to upgrade libraries which depend upon it.
>                         This is primarily under
>                         the control of the CLC and library maintainers,
>                         however, not the GHC
>                         team. It would help if base was minimal and
>                         reinstallable, but that
>                         isn't a total solution either, because you'd
>                         still have to worry about
>                         packages depending on template-haskell or the
>                         ghc package itself.
> 
>                            * Performance regressions or critical bugs.
>                         These tend to be a
>                         significant obstacle to upgrading for smaller
>                         commercial users. But
>                         spending more of our limited resources on
>                         stability of the language
>                         means fewer resources for resolving these issues.
> 
>                         There's surely more we can do here, but let's be
>                         careful not to pay too
>                         many costs to achieve stability of the
>                         *language* alone, when stability
>                         of the *libraries* and *implementation* are both
>                         more important and
>                         harder to fix.
> 
>                         Adam
> 
> 
>                         On 22/09/2023 10:53, Simon Peyton Jones wrote:
>                          > Dear GHC SC
>                          >
>                          > To avoid derailing the debate about -Wsevere
>                          >
>                         <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>>, I'm starting a new (email for now) thread about stability.
>                          >
>                          > I have tried to articulate what I believe is
>                         an evolving consensus in
>                          > this document
>                          >
>                         <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>>.
>                          >
>                          > If we converge, we'll turn that into a proper
>                         PR for the GHC proposal
>                          > process, although it has wider implications
>                         than just GHC proposals and
>                          > we should share with a broader audience.  But
>                         let's start with the
>                          > steering committee.
>                          >
>                          > Any views?  You all have edit rights.
>                          >
>                          > I think that the draft covers Moritz's and
>                         Julian's goals, at least that
>                          > was my intention.  I have pasted Moritz's
>                         last email below, for context.
>                          >
>                          > Simon
>                          >
>                          >
>                          > ========= Moritz's last email ============
>                          >
>                          > Now, this is derailing the original
>                         discussion a bit, and I'm not sure
>                          > how far we want to take this. But, regarding
>                         @Simon Marlow
>                          > <mailto:marlowsd at gmail.com
>                         <mailto:marlowsd at gmail.com>>'s comment
>                          >
>                          >     This is one cultural aspect of our
>                         community I'd like to shift: the
>                          >     expectation that it's OK to make breaking
>                         changes as long as you
>                          >     warn about
>                          >     them or go through a migration cycle. It
>                         just isn't! (and I speak as
>                          >     someone who used to make lots of changes,
>                         I'm now fully repentant!).
>                          >     That's
>                          >     not to say that we shouldn't ever change
>                         anything, but when
>                          >     considering the
>                          >     cost/benefit tradeoff adding a migration
>                         cycle doesn't reduce the
>                          >     cost, it
>                          >     just defers it.
>                          >
>                          >
>                          > I actually read this as we should stop having
>                         breaking changes to begin
>                          > with. And _if_ we
>                          > do have breaking changes, that deprecation
>                         does not change the need to
>                          > actually change
>                          > code (cost). As outlined in my reply to that,
>                         and @Richard Eisenberg
>                          > <mailto:lists at richarde.dev
>                         <mailto:lists at richarde.dev>>'s observation, it
>                          > "smears" the cost. The--to me--_much_ bigger
>                         implication of deprecation
>                          > cycles is that we
>                          > _inform_ our _customers_ about upcoming
>                         changes _early_, instead of
>                          > _after the fact_. We
>                          > also give them ample time to react. Being by
>                         changing their code, or
>                          > raising their concerns.
>                          > Would the Simplified Subsumptions / Deep
>                         Subsumptions change have looked
>                          > differently?
>                          > As such I see deprecation cycles as
>                         orthogonal to the question if we
>                          > should have breaking
>                          > changes to begin with.
>                          >
>                          > Thus I believe the following:
>                          >
>                          >     - Do have a deprecation cycle if possible.
>                          >     - Do not treat a deprecation cycle as an
>                         excuse.  Costs are deferred
>                          >     but are as large as ever.
>                          >
>                          >
>                          > should be upgraded to:
>                          > - Preferably _no_ breaking changes.
>                          > - If breaking changes, then with a
>                         deprecation cycle, unless technically
>                          > infeasible.
>                          > - An understanding that any breaking change
>                         incurs significant costs.
>                          >
>                          > Ocaml recently added multicore support, and
>                         they put tremendous effort
>                          > into making
>                          > sure it keeps backwards compatibility:
>                          >
>                         https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>                          >
>                         <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>>
>                          >
>                          >     PS: we should also agree that a "stable"
>                         extension should not
>                          >     require dependencies on
>                         ghc-experimental.  To become stable, any
>                          >     library support for an extension must
>                         move into `base`.
>                          >
>                          >
>                          > This seems like a good idea, however I still
>                         remain that _experimental_
>                          > features should not be on-by-default in a
>                         stable compiler. Yes, ideally
>                          > I'd not even see them in a stable compiler,
>                         but I know this view is
>                          > contentious. The use of `ghc-experimental`
>                         should therefore be guarded
>                          > by `--std=experimental` as Julian suggested.
>                         That is a loud opt-in to
>                          > experimental features.
>                          >
> 


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From chris at chrisdornan.com  Fri Sep 29 06:49:52 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 29 Sep 2023 07:49:52 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions (rec:
 accept)
In-Reply-To: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
Message-ID: <F461732F-D1C2-4C93-87C6-2D342B3E7D28@chrisdornan.com>

Works for me: +1 for accepting #526.

> On 28 Sep 2023, at 08:12, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> Dear committee,
> 
> #526 proposes a new extension ApplicativeComprehensions (implying MonadComprehensions). It would provide the equivalent of the current ApplicativeDo desugaring for do-expressions to list comprehensions.
> Github thread <https://github.com/ghc-proposals/ghc-proposals/pull/526>
> Rendered <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst>
> The extension itself is relatively uncontroversial, but there are some unresolved quirks in the original ApplicativeDo extension which made us uneasy about extending it. However, after various discussions I'm going to propose accepting this proposal in its current state.  Rationale:
> It doesn't make things worse, and the implementation isn't likely to add significant complexity.
> It retains consistency between ApplicativeDo and ApplicativeComprehensions (in contrast to the idea of making ApplicativeComprehensions perform a simpler desugaring, which came up during the discussion)
> A future proposal can add a simpler version of the desugaring for both extensions later.
> 
> Cheers
> Simon
> _______________________________________________
> 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/20230929/23fda9c9/attachment.html>

From chris at chrisdornan.com  Fri Sep 29 07:31:18 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 29 Sep 2023 08:31:18 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
Message-ID: <5A826B6E-4FD5-463D-A837-3AF4D8061B3B@chrisdornan.com>

Moritz's analysis of why breaking changes are so costly for the whole enterprise is so clarifying; I doubt if there is much that we are considering of more importance.

Let me know Moritz if I can help with anything.

Chris

> On 28 Sep 2023, at 13:39, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> Simon,
> 
> Thank you for bringing us this far. I'd be happy to step up to drive this further.
> 
> I will say that I do see the tension you see as well. And I do believe if we come to a conclusion on this stability policy that it will
> make GHC development more rigorous, which I think is a good thing for all of us, not just the consumers of the compiler. I think
> we need to stay mindful that we can still freely experiment on the --std=experimental (or however that flag ends up being named)
> side. I see this whole discussion as leading us towards the language research reactor side of GHC being primarily confined behind
> --std=experimental, and the stability seeking (commercial application?) on the other side.
> 
> I do not yet see how we can end up with the inability to change. We will just have a clearer process for _breaking_ changes. This
> does absolutely not mean we have to end up in a local optimum, or that we can not change. We can!
> 
> Unless someone speaks up who does _not_ want me to drive, this, I'm happy to start driving this discussion (including writing the
> proposals, starting next week).
> 
> Best,
>  Moritz
> 
> On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>> Should we have a document (or better spreadsheet?) with a bullet point for each experimental feature to be considered? I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable. As such I’d like to propose that we’d add to each features a counter for how much of hackage (as a proxy for real world usage) uses the specific feature.  
>> 
>> I think that would be a helpful way to "ground" the discussion a bit more.  (The spreadsheet should also give a preliminary classification of extensions, at least into stable/experimental.)
>> 
>> I'm running out of capacity to drive this debate, useful though it is.  Does anyone else feel able to drive some of the legwork?
>> 
>> So far this is all informal committee discussion.  The next step would be a GHC Proposal inviting broader feedback from the community.  I'm just hoping that by debugging it between ourselves we can side-step some unproductive discussions in that bigger context.
>> 
>>> I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable 
>> 
>> There is a tension here.  If we say something is "stable" then we have to be super-careful about changing it.  (That's the whole point.)  And yet if the feature (like INCOHERENT) is a flaky "you are on your own" unsafePerformIO-like feature, I am axious about tying ourselves into an inability to change the behaviour of corner cases.  I'm not sure how to resolve this tension.
>> 
>> Simon
>> 
>>  
>> 
>> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> I think we are moving in the right direction! I do see however the tension rising on (2). And without being clear about (2), I don’t think we can properly agree on (1). We can agree on (1) in principle, but we need to clarify what we consider unstable/experimental, as a precondition to have finale agreement on (1). Otherwise people might agree to (1), only to be surprised by (2). For (3), I’d be happy to try to get my employer to provide resources for the implementation of —std=experimental. 
>>> 
>>> Thusly I believe we should start to build a list of features we consider sufficiently experimental that they should preclude an existing Haskell program from being considered stable. This list for me contains so far:
>>> 
>>> - Linear Types
>>> - Dependent Haskell
>>> 
>>> Adam pointed out experimental backend and non-tire-1 platforms. I tend to agree with this, but see this distinctly separate from the language stability (outside of backend specific language extensions, e.g. JSFFI).
>>> 
>>> Platforms/backends may be experimental but those are (safe for specific lang exts) orthogonal to the Haskell code the compiler accepts.
>>> 
>>> Should we have a document (or better spreadsheet?) with a bullet point for each experimental feature to be considered? I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable. As such I’d like to propose that we’d add to each features a counter for how much of hackage (as a proxy for real world usage) uses the specific feature.  
>>> 
>>> Best,
>>>  Moritz
>>> 
>>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>> it's essential that we continue to have these discussions to ensure we're making the best decisions for the project and our community. 
>>>> 
>>>> Yes exactly!  Its tricky and nuanced; hence trying to articulate something in a concrete doc, so we are all on the same page (literally!).
>>>> 
>>>>> However, deprecation cycles don't mean we're averse to major changes. It means we introduce them responsibly. When we believe a superior design is possible, we can start a deprecation process to transition towards it.
>>>> 
>>>> I have tried to make this explicit in Section 4.   See what you think.
>>>> 
>>>> I think there are three phases
>>>> Agree this document.  Is it what we want.
>>>> Categorise extensions into stable/experimental, and identify experimental language features.
>>>> Implement --std=experimental (Section 6).
>>>> (1) is what we are doing now.  (2) will be some work, done by us.  (3) is a larger task: it will require significant work to implement, and may impose unwelcome churn of its own.  But that should not stop us doing (1) and (2).
>>>> 
>>>> Simon
>>>> 
>>>> 
>>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>>> Dear Adam,
>>>>> 
>>>>> Thank you for your thoughtful feedback. I understand your reservations, and it's essential that we continue to have these discussions to ensure we're making the best decisions for the project and our community. Let me address each of your points in turn:
>>>>> 
>>>>> - Cognitive Overhead for Users:
>>>>> I understand the concern about cognitive overhead due to the inability to remove complexity. However, our primary intention is to ensure a gradual transition for our users rather than abrupt shifts. Introducing changes via deprecation cycles allows users to adjust to modifications over time, reducing the immediate cognitive load. It's a balance between stability and simplicity, and I believe this approach allows us still to reduce complexity.
>>>>> 
>>>>> - Maintenance Burden in the Compiler:
>>>>> Maintaining backward compatibility does indeed introduce some overhead. Still, it also encourages a more disciplined and considered approach to changes. With our deprecation cycles in place, it's not that we never remove complexity; rather, we do it in a way that provides ample time for adjustments. This benefits both the development team and the community.
>>>>> 
>>>>> - Risk of Local Optimum:
>>>>> This is a valid concern. However, deprecation cycles don't mean we're averse to major changes. It means we introduce them responsibly. When we believe a superior design is possible, we can start a deprecation process to transition towards it. The flexibility and duration of our deprecation cycles can be tailored depending on the severity of the breaking change.
>>>>> 
>>>>> - Discouraging Volunteer Contributors:
>>>>> I understand that lengthy approval processes can be off-putting. But it's crucial to note that a rigorous process ensures the consistency and reliability of our project. We always welcome and value contributions. Moreover, I believe this stability policy will provide us with clear guardrails on how changes can be contributed.
>>>>> 
>>>>> I will not disagree on the costs. I do believe though that the costs for _breaking_ changes in the compiler ought to be borne by the people making the change, instead of those who use the compiler (and may not even benefit of those changes that caused breakage). I also see the team maintaining GHC as the one to enforce this; they are the ones who cut the releases. The fact that we may have breaking changes due to _bugs_ is covered explicitly in the stability policy document.
>>>>> 
>>>>> With my CLC hat on, I have been focusing on the same stability guidelines as well (if it breaks existing code, I have been against those changes without deprecation policies). The issues with the template-haskell, and ghc library are noted. For the ghc library the question will remain if we intent to provide a stable api to the compiler or not. I believe many tools would like to have one, and if we relegate anything unstable to ghc-experimental this might be achieved. For template-haskell this is a bigger concern. Maybe we can collectively come up with a solution that would allow us to provide a more insulated template haskell interface from the compiler.
>>>>> 
>>>>> However for template-haskell we might also need to look at what exactly caused those breaking changes in the past.
>>>>> 
>>>>> What this document outlines (in my understanding) is that any experimental feature development can _only_ be visible behind --std=experimental, and the dependency of ghc-experimental. Unless those are given, the compiler should accept existing programs. This should allow us enough room to innovate (everyone is always free to opt-in to bleeding edge features with --std=experimental).  I also believe that most of what we have today will need to be treated as non-experimental simply because we did not have that mechanism before. We don't want to break existing programs as much as possible, thus relegating existing features into --std=experimental (except for some fairly clear ones: e.g. Dependent Haskell, and Linear Types?) is not really possible. What we can however do is start deprecation phases for a few versions, moving features we consider highly experimental (or maybe even bad) into `--std=experimental`. Just by having deprecation phases and given the ecosystem enough time to adjust (and provide feedback) we might come to different conclusions.
>>>>> 
>>>>> As I've also outlined in the document, _if_ GHC was trivially swappable, companies like IOG would _love_ to try new compilers and report back bugs and regressions. As it is today, we can't. Making a large live codebase compatible with 9.8 is a multiple weeks effort. Experimenting with nightlies is technically impossible. _If_ I could setup the built of our software trivial with ghc nightlies, I'd be _happy_ to build the infrastructure out it to provide performance regressions (compilation, runtime, ...) for our codebase and provide the feedback to the GHC team; however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2 today. 9.6 maybe soon, but likely at the point in time where 9.6 is not going to see any further releases, so I can spare trying to even forward port my patches to HEAD. Not that I could even test them with head properly, as our source is not accepted by HEAD. Thus I end up writing patches against old stale branches. This to me is a fairly big discouragement from contributing to GHC.
>>>>> 
>>>>> Best,
>>>>>  Moritz
>>>>> 
>>>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>>> 
>>>>>> A strong stability guarantee is certainly a valuable goal, but it also 
>>>>>> comes with costs, which I'd like to see more clearly articulated. Some 
>>>>>> of them include:
>>>>>> 
>>>>>>   * Cognitive overhead for users, because of the inability to remove 
>>>>>> complexity from the design.
>>>>>> 
>>>>>>   * Increasing maintenance burden in the compiler, because of the 
>>>>>> additional work needed to implement new features and the inability to 
>>>>>> remove complexity from the implementation.
>>>>>> 
>>>>>>   * A risk of getting stuck in a local optimum, because moving to a 
>>>>>> better design would entail breaking changes.
>>>>>> 
>>>>>>   * Discouraging volunteer contributors, who are much less likely to 
>>>>>> work on a potentially beneficial change if the process for getting it 
>>>>>> approved is too onerous. (I'm worried we're already reaching that point 
>>>>>> due to the increasing burden of well-intentioned processes.)
>>>>>> 
>>>>>> Ultimately every proposed change has a cost-benefit trade-off, with risk 
>>>>>> of breakage being one of the costs. We need to consciously evaluate that 
>>>>>> trade-off on a case-by-case basis. Almost all changes might break 
>>>>>> something (e.g. by regressing performance, or for Hyrum's Law reasons), 
>>>>>> so there needs to be a proportionate assessment of how likely each 
>>>>>> change is to be damaging in practice, bearing in mind that such an 
>>>>>> assessment is itself costly and limited in scope.
>>>>>> 
>>>>>> It seems to me that the GHC team have taken on board lessons regarding 
>>>>>> stability of the language, and the extension system already gives quite 
>>>>>> a lot of flexibility to evolve the language in a backwards-compatible 
>>>>>> way. In my experience, the key stability problems preventing upgrades to 
>>>>>> recent GHC releases are:
>>>>>> 
>>>>>>   * The cascading effect of breaking changes in one library causing the 
>>>>>> need to upgrade libraries which depend upon it. This is primarily under 
>>>>>> the control of the CLC and library maintainers, however, not the GHC 
>>>>>> team. It would help if base was minimal and reinstallable, but that 
>>>>>> isn't a total solution either, because you'd still have to worry about 
>>>>>> packages depending on template-haskell or the ghc package itself.
>>>>>> 
>>>>>>   * Performance regressions or critical bugs. These tend to be a 
>>>>>> significant obstacle to upgrading for smaller commercial users. But 
>>>>>> spending more of our limited resources on stability of the language 
>>>>>> means fewer resources for resolving these issues.
>>>>>> 
>>>>>> There's surely more we can do here, but let's be careful not to pay too 
>>>>>> many costs to achieve stability of the *language* alone, when stability 
>>>>>> of the *libraries* and *implementation* are both more important and 
>>>>>> harder to fix.
>>>>>> 
>>>>>> Adam
>>>>>> 
>>>>>> 
>>>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>>>> > Dear GHC SC
>>>>>> > 
>>>>>> > To avoid derailing the debate about -Wsevere 
>>>>>> > <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
>>>>>> > 
>>>>>> > I have tried to articulate what I believe is an evolving consensus in 
>>>>>> > this document 
>>>>>> > <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
>>>>>> > 
>>>>>> > If we converge, we'll turn that into a proper PR for the GHC proposal 
>>>>>> > process, although it has wider implications than just GHC proposals and 
>>>>>> > we should share with a broader audience.  But let's start with the 
>>>>>> > steering committee.
>>>>>> > 
>>>>>> > Any views?  You all have edit rights.
>>>>>> > 
>>>>>> > I think that the draft covers Moritz's and Julian's goals, at least that 
>>>>>> > was my intention.  I have pasted Moritz's last email below, for context.
>>>>>> > 
>>>>>> > Simon
>>>>>> > 
>>>>>> > 
>>>>>> > ========= Moritz's last email ============
>>>>>> > 
>>>>>> > Now, this is derailing the original discussion a bit, and I'm not sure 
>>>>>> > how far we want to take this. But, regarding @Simon Marlow 
>>>>>> > <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>'s comment
>>>>>> > 
>>>>>> >     This is one cultural aspect of our community I'd like to shift: the
>>>>>> >     expectation that it's OK to make breaking changes as long as you
>>>>>> >     warn about
>>>>>> >     them or go through a migration cycle. It just isn't! (and I speak as
>>>>>> >     someone who used to make lots of changes, I'm now fully repentant!).
>>>>>> >     That's
>>>>>> >     not to say that we shouldn't ever change anything, but when
>>>>>> >     considering the
>>>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>>>>>> >     cost, it
>>>>>> >     just defers it.
>>>>>> > 
>>>>>> > 
>>>>>> > I actually read this as we should stop having breaking changes to begin 
>>>>>> > with. And _if_ we
>>>>>> > do have breaking changes, that deprecation does not change the need to 
>>>>>> > actually change
>>>>>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg 
>>>>>> > <mailto:lists at richarde.dev <mailto:lists at richarde.dev>>'s observation, it
>>>>>> > "smears" the cost. The--to me--_much_ bigger implication of deprecation 
>>>>>> > cycles is that we
>>>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of 
>>>>>> > _after the fact_. We
>>>>>> > also give them ample time to react. Being by changing their code, or 
>>>>>> > raising their concerns.
>>>>>> > Would the Simplified Subsumptions / Deep Subsumptions change have looked 
>>>>>> > differently?
>>>>>> > As such I see deprecation cycles as orthogonal to the question if we 
>>>>>> > should have breaking
>>>>>> > changes to begin with.
>>>>>> > 
>>>>>> > Thus I believe the following:
>>>>>> > 
>>>>>> >     - Do have a deprecation cycle if possible.
>>>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>>>>>> >     but are as large as ever.
>>>>>> > 
>>>>>> > 
>>>>>> > should be upgraded to:
>>>>>> > - Preferably _no_ breaking changes.
>>>>>> > - If breaking changes, then with a deprecation cycle, unless technically 
>>>>>> > infeasible.
>>>>>> > - An understanding that any breaking change incurs significant costs.
>>>>>> > 
>>>>>> > Ocaml recently added multicore support, and they put tremendous effort 
>>>>>> > into making
>>>>>> > sure it keeps backwards compatibility: 
>>>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md 
>>>>>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>>>>> > 
>>>>>> >     PS: we should also agree that a "stable" extension should not
>>>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>>>> >     library support for an extension must move into `base`.
>>>>>> > 
>>>>>> > 
>>>>>> > This seems like a good idea, however I still remain that _experimental_ 
>>>>>> > features should not be on-by-default in a stable compiler. Yes, ideally 
>>>>>> > I'd not even see them in a stable compiler, but I know this view is 
>>>>>> > contentious. The use of `ghc-experimental` should therefore be guarded 
>>>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to 
>>>>>> > experimental features.
>>>>>> > 
>>>>>> 
>>>>>> -- 
>>>>>> Adam Gundry, Haskell Consultant
>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>> 
>>>>>> Registered in England & Wales, OC335890
>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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
>>>>> _______________________________________________
>>>>> 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
> _______________________________________________
> 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/20230929/549ad500/attachment-0001.html>

From chris at chrisdornan.com  Fri Sep 29 07:42:27 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 29 Sep 2023 08:42:27 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAJKmMz-V6J5U=zvVGRpe3BvM08w5_7LV2wm2BbtFsmNe8oAUTA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
 <CAJKmMz-V6J5U=zvVGRpe3BvM08w5_7LV2wm2BbtFsmNe8oAUTA@mail.gmail.com>
Message-ID: <6535BA52-7CBE-4007-90BE-C1F327C31637@chrisdornan.com>

I have been pretty desperate for us to start taking stability seriously for some years now. Part of the reason for this is to give us the space to make breaking changes when we really need to. Should we discover a compelling reason to introduce a breaking change to the compiler then it would be difficult to do without creating a lot of resentment in the community because we have so little clarity in this area.

If we succeed in establishing this framework then I would hope that we would find it easier to hold a conversation with the community about the kind of change that Adam is concerned about -- because we would have established credibility in this area.

Chris

> On 28 Sep 2023, at 14:15, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> I do not yet see how we can end up with the inability to change. We will just have a clearer process for _breaking_ changes. This
>> does absolutely not mean we have to end up in a local optimum, or that we can not change. We can
> 
> Agreed that stable features are not unable to change... it's just that the bar is higher (that's the intent), so change is more expensive.  E.g. suppose we want to change some fine point about the semantics of INCOHERENT.  It might be difficult to have both the old semantics and the new, and somehow give a deprecation warning.  And INCOHERENT is already saying "I know that the ice is thin here and I'm signed up to the consequences". 
> 
> You are reminding us that if a feature is widely depended on, changing it imposes real costs on users.  I'm reminding us that making more things "stable" imposes real costs on GHC's design and implementation team -- on whom we all rely.  Both concerns are legitimate. We will need to debate each stable/experimental choice on a case by case basis, informed (among other things) but how widely used they are.
> 
> Simon
> 
> 
> On Thu, 28 Sept 2023 at 13:39, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>> Simon,
>> 
>> Thank you for bringing us this far. I'd be happy to step up to drive this further.
>> 
>> I will say that I do see the tension you see as well. And I do believe if we come to a conclusion on this stability policy that it will
>> make GHC development more rigorous, which I think is a good thing for all of us, not just the consumers of the compiler. I think
>> we need to stay mindful that we can still freely experiment on the --std=experimental (or however that flag ends up being named)
>> side. I see this whole discussion as leading us towards the language research reactor side of GHC being primarily confined behind
>> --std=experimental, and the stability seeking (commercial application?) on the other side.
>> 
>> I do not yet see how we can end up with the inability to change. We will just have a clearer process for _breaking_ changes. This
>> does absolutely not mean we have to end up in a local optimum, or that we can not change. We can!
>> 
>> Unless someone speaks up who does _not_ want me to drive, this, I'm happy to start driving this discussion (including writing the
>> proposals, starting next week).
>> 
>> Best,
>>  Moritz
>> 
>> On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>> Should we have a document (or better spreadsheet?) with a bullet point for each experimental feature to be considered? I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable. As such I’d like to propose that we’d add to each features a counter for how much of hackage (as a proxy for real world usage) uses the specific feature.  
>>> 
>>> I think that would be a helpful way to "ground" the discussion a bit more.  (The spreadsheet should also give a preliminary classification of extensions, at least into stable/experimental.)
>>> 
>>> I'm running out of capacity to drive this debate, useful though it is.  Does anyone else feel able to drive some of the legwork?
>>> 
>>> So far this is all informal committee discussion.  The next step would be a GHC Proposal inviting broader feedback from the community.  I'm just hoping that by debugging it between ourselves we can side-step some unproductive discussions in that bigger context.
>>> 
>>>> I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable 
>>> 
>>> There is a tension here.  If we say something is "stable" then we have to be super-careful about changing it.  (That's the whole point.)  And yet if the feature (like INCOHERENT) is a flaky "you are on your own" unsafePerformIO-like feature, I am axious about tying ourselves into an inability to change the behaviour of corner cases.  I'm not sure how to resolve this tension.
>>> 
>>> Simon
>>> 
>>>  
>>> 
>>> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>> I think we are moving in the right direction! I do see however the tension rising on (2). And without being clear about (2), I don’t think we can properly agree on (1). We can agree on (1) in principle, but we need to clarify what we consider unstable/experimental, as a precondition to have finale agreement on (1). Otherwise people might agree to (1), only to be surprised by (2). For (3), I’d be happy to try to get my employer to provide resources for the implementation of —std=experimental. 
>>>> 
>>>> Thusly I believe we should start to build a list of features we consider sufficiently experimental that they should preclude an existing Haskell program from being considered stable. This list for me contains so far:
>>>> 
>>>> - Linear Types
>>>> - Dependent Haskell
>>>> 
>>>> Adam pointed out experimental backend and non-tire-1 platforms. I tend to agree with this, but see this distinctly separate from the language stability (outside of backend specific language extensions, e.g. JSFFI).
>>>> 
>>>> Platforms/backends may be experimental but those are (safe for specific lang exts) orthogonal to the Haskell code the compiler accepts.
>>>> 
>>>> Should we have a document (or better spreadsheet?) with a bullet point for each experimental feature to be considered? I believe we need to take into account that we can’t end up classifying most of todays Haskell programs unstable. As such I’d like to propose that we’d add to each features a counter for how much of hackage (as a proxy for real world usage) uses the specific feature.  
>>>> 
>>>> Best,
>>>>  Moritz
>>>> 
>>>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>>>>> it's essential that we continue to have these discussions to ensure we're making the best decisions for the project and our community. 
>>>>> 
>>>>> Yes exactly!  Its tricky and nuanced; hence trying to articulate something in a concrete doc, so we are all on the same page (literally!).
>>>>> 
>>>>>> However, deprecation cycles don't mean we're averse to major changes. It means we introduce them responsibly. When we believe a superior design is possible, we can start a deprecation process to transition towards it.
>>>>> 
>>>>> I have tried to make this explicit in Section 4.   See what you think.
>>>>> 
>>>>> I think there are three phases
>>>>> Agree this document.  Is it what we want.
>>>>> Categorise extensions into stable/experimental, and identify experimental language features.
>>>>> Implement --std=experimental (Section 6).
>>>>> (1) is what we are doing now.  (2) will be some work, done by us.  (3) is a larger task: it will require significant work to implement, and may impose unwelcome churn of its own.  But that should not stop us doing (1) and (2).
>>>>> 
>>>>> Simon
>>>>> 
>>>>> 
>>>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>>>>> Dear Adam,
>>>>>> 
>>>>>> Thank you for your thoughtful feedback. I understand your reservations, and it's essential that we continue to have these discussions to ensure we're making the best decisions for the project and our community. Let me address each of your points in turn:
>>>>>> 
>>>>>> - Cognitive Overhead for Users:
>>>>>> I understand the concern about cognitive overhead due to the inability to remove complexity. However, our primary intention is to ensure a gradual transition for our users rather than abrupt shifts. Introducing changes via deprecation cycles allows users to adjust to modifications over time, reducing the immediate cognitive load. It's a balance between stability and simplicity, and I believe this approach allows us still to reduce complexity.
>>>>>> 
>>>>>> - Maintenance Burden in the Compiler:
>>>>>> Maintaining backward compatibility does indeed introduce some overhead. Still, it also encourages a more disciplined and considered approach to changes. With our deprecation cycles in place, it's not that we never remove complexity; rather, we do it in a way that provides ample time for adjustments. This benefits both the development team and the community.
>>>>>> 
>>>>>> - Risk of Local Optimum:
>>>>>> This is a valid concern. However, deprecation cycles don't mean we're averse to major changes. It means we introduce them responsibly. When we believe a superior design is possible, we can start a deprecation process to transition towards it. The flexibility and duration of our deprecation cycles can be tailored depending on the severity of the breaking change.
>>>>>> 
>>>>>> - Discouraging Volunteer Contributors:
>>>>>> I understand that lengthy approval processes can be off-putting. But it's crucial to note that a rigorous process ensures the consistency and reliability of our project. We always welcome and value contributions. Moreover, I believe this stability policy will provide us with clear guardrails on how changes can be contributed.
>>>>>> 
>>>>>> I will not disagree on the costs. I do believe though that the costs for _breaking_ changes in the compiler ought to be borne by the people making the change, instead of those who use the compiler (and may not even benefit of those changes that caused breakage). I also see the team maintaining GHC as the one to enforce this; they are the ones who cut the releases. The fact that we may have breaking changes due to _bugs_ is covered explicitly in the stability policy document.
>>>>>> 
>>>>>> With my CLC hat on, I have been focusing on the same stability guidelines as well (if it breaks existing code, I have been against those changes without deprecation policies). The issues with the template-haskell, and ghc library are noted. For the ghc library the question will remain if we intent to provide a stable api to the compiler or not. I believe many tools would like to have one, and if we relegate anything unstable to ghc-experimental this might be achieved. For template-haskell this is a bigger concern. Maybe we can collectively come up with a solution that would allow us to provide a more insulated template haskell interface from the compiler.
>>>>>> 
>>>>>> However for template-haskell we might also need to look at what exactly caused those breaking changes in the past.
>>>>>> 
>>>>>> What this document outlines (in my understanding) is that any experimental feature development can _only_ be visible behind --std=experimental, and the dependency of ghc-experimental. Unless those are given, the compiler should accept existing programs. This should allow us enough room to innovate (everyone is always free to opt-in to bleeding edge features with --std=experimental).  I also believe that most of what we have today will need to be treated as non-experimental simply because we did not have that mechanism before. We don't want to break existing programs as much as possible, thus relegating existing features into --std=experimental (except for some fairly clear ones: e.g. Dependent Haskell, and Linear Types?) is not really possible. What we can however do is start deprecation phases for a few versions, moving features we consider highly experimental (or maybe even bad) into `--std=experimental`. Just by having deprecation phases and given the ecosystem enough time to adjust (and provide feedback) we might come to different conclusions.
>>>>>> 
>>>>>> As I've also outlined in the document, _if_ GHC was trivially swappable, companies like IOG would _love_ to try new compilers and report back bugs and regressions. As it is today, we can't. Making a large live codebase compatible with 9.8 is a multiple weeks effort. Experimenting with nightlies is technically impossible. _If_ I could setup the built of our software trivial with ghc nightlies, I'd be _happy_ to build the infrastructure out it to provide performance regressions (compilation, runtime, ...) for our codebase and provide the feedback to the GHC team; however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2 today. 9.6 maybe soon, but likely at the point in time where 9.6 is not going to see any further releases, so I can spare trying to even forward port my patches to HEAD. Not that I could even test them with head properly, as our source is not accepted by HEAD. Thus I end up writing patches against old stale branches. This to me is a fairly big discouragement from contributing to GHC.
>>>>>> 
>>>>>> Best,
>>>>>>  Moritz
>>>>>> 
>>>>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com <mailto:adam at well-typed.com>> wrote:
>>>>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>>>> 
>>>>>>> A strong stability guarantee is certainly a valuable goal, but it also 
>>>>>>> comes with costs, which I'd like to see more clearly articulated. Some 
>>>>>>> of them include:
>>>>>>> 
>>>>>>>   * Cognitive overhead for users, because of the inability to remove 
>>>>>>> complexity from the design.
>>>>>>> 
>>>>>>>   * Increasing maintenance burden in the compiler, because of the 
>>>>>>> additional work needed to implement new features and the inability to 
>>>>>>> remove complexity from the implementation.
>>>>>>> 
>>>>>>>   * A risk of getting stuck in a local optimum, because moving to a 
>>>>>>> better design would entail breaking changes.
>>>>>>> 
>>>>>>>   * Discouraging volunteer contributors, who are much less likely to 
>>>>>>> work on a potentially beneficial change if the process for getting it 
>>>>>>> approved is too onerous. (I'm worried we're already reaching that point 
>>>>>>> due to the increasing burden of well-intentioned processes.)
>>>>>>> 
>>>>>>> Ultimately every proposed change has a cost-benefit trade-off, with risk 
>>>>>>> of breakage being one of the costs. We need to consciously evaluate that 
>>>>>>> trade-off on a case-by-case basis. Almost all changes might break 
>>>>>>> something (e.g. by regressing performance, or for Hyrum's Law reasons), 
>>>>>>> so there needs to be a proportionate assessment of how likely each 
>>>>>>> change is to be damaging in practice, bearing in mind that such an 
>>>>>>> assessment is itself costly and limited in scope.
>>>>>>> 
>>>>>>> It seems to me that the GHC team have taken on board lessons regarding 
>>>>>>> stability of the language, and the extension system already gives quite 
>>>>>>> a lot of flexibility to evolve the language in a backwards-compatible 
>>>>>>> way. In my experience, the key stability problems preventing upgrades to 
>>>>>>> recent GHC releases are:
>>>>>>> 
>>>>>>>   * The cascading effect of breaking changes in one library causing the 
>>>>>>> need to upgrade libraries which depend upon it. This is primarily under 
>>>>>>> the control of the CLC and library maintainers, however, not the GHC 
>>>>>>> team. It would help if base was minimal and reinstallable, but that 
>>>>>>> isn't a total solution either, because you'd still have to worry about 
>>>>>>> packages depending on template-haskell or the ghc package itself.
>>>>>>> 
>>>>>>>   * Performance regressions or critical bugs. These tend to be a 
>>>>>>> significant obstacle to upgrading for smaller commercial users. But 
>>>>>>> spending more of our limited resources on stability of the language 
>>>>>>> means fewer resources for resolving these issues.
>>>>>>> 
>>>>>>> There's surely more we can do here, but let's be careful not to pay too 
>>>>>>> many costs to achieve stability of the *language* alone, when stability 
>>>>>>> of the *libraries* and *implementation* are both more important and 
>>>>>>> harder to fix.
>>>>>>> 
>>>>>>> Adam
>>>>>>> 
>>>>>>> 
>>>>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>>>>> > Dear GHC SC
>>>>>>> > 
>>>>>>> > To avoid derailing the debate about -Wsevere 
>>>>>>> > <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>, and HasField redesign <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>, I'm starting a new (email for now) thread about stability.
>>>>>>> > 
>>>>>>> > I have tried to articulate what I believe is an evolving consensus in 
>>>>>>> > this document 
>>>>>>> > <https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing>.
>>>>>>> > 
>>>>>>> > If we converge, we'll turn that into a proper PR for the GHC proposal 
>>>>>>> > process, although it has wider implications than just GHC proposals and 
>>>>>>> > we should share with a broader audience.  But let's start with the 
>>>>>>> > steering committee.
>>>>>>> > 
>>>>>>> > Any views?  You all have edit rights.
>>>>>>> > 
>>>>>>> > I think that the draft covers Moritz's and Julian's goals, at least that 
>>>>>>> > was my intention.  I have pasted Moritz's last email below, for context.
>>>>>>> > 
>>>>>>> > Simon
>>>>>>> > 
>>>>>>> > 
>>>>>>> > ========= Moritz's last email ============
>>>>>>> > 
>>>>>>> > Now, this is derailing the original discussion a bit, and I'm not sure 
>>>>>>> > how far we want to take this. But, regarding @Simon Marlow 
>>>>>>> > <mailto:marlowsd at gmail.com <mailto:marlowsd at gmail.com>>'s comment
>>>>>>> > 
>>>>>>> >     This is one cultural aspect of our community I'd like to shift: the
>>>>>>> >     expectation that it's OK to make breaking changes as long as you
>>>>>>> >     warn about
>>>>>>> >     them or go through a migration cycle. It just isn't! (and I speak as
>>>>>>> >     someone who used to make lots of changes, I'm now fully repentant!).
>>>>>>> >     That's
>>>>>>> >     not to say that we shouldn't ever change anything, but when
>>>>>>> >     considering the
>>>>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce the
>>>>>>> >     cost, it
>>>>>>> >     just defers it.
>>>>>>> > 
>>>>>>> > 
>>>>>>> > I actually read this as we should stop having breaking changes to begin 
>>>>>>> > with. And _if_ we
>>>>>>> > do have breaking changes, that deprecation does not change the need to 
>>>>>>> > actually change
>>>>>>> > code (cost). As outlined in my reply to that, and @Richard Eisenberg 
>>>>>>> > <mailto:lists at richarde.dev <mailto:lists at richarde.dev>>'s observation, it
>>>>>>> > "smears" the cost. The--to me--_much_ bigger implication of deprecation 
>>>>>>> > cycles is that we
>>>>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of 
>>>>>>> > _after the fact_. We
>>>>>>> > also give them ample time to react. Being by changing their code, or 
>>>>>>> > raising their concerns.
>>>>>>> > Would the Simplified Subsumptions / Deep Subsumptions change have looked 
>>>>>>> > differently?
>>>>>>> > As such I see deprecation cycles as orthogonal to the question if we 
>>>>>>> > should have breaking
>>>>>>> > changes to begin with.
>>>>>>> > 
>>>>>>> > Thus I believe the following:
>>>>>>> > 
>>>>>>> >     - Do have a deprecation cycle if possible.
>>>>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are deferred
>>>>>>> >     but are as large as ever.
>>>>>>> > 
>>>>>>> > 
>>>>>>> > should be upgraded to:
>>>>>>> > - Preferably _no_ breaking changes.
>>>>>>> > - If breaking changes, then with a deprecation cycle, unless technically 
>>>>>>> > infeasible.
>>>>>>> > - An understanding that any breaking change incurs significant costs.
>>>>>>> > 
>>>>>>> > Ocaml recently added multicore support, and they put tremendous effort 
>>>>>>> > into making
>>>>>>> > sure it keeps backwards compatibility: 
>>>>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md 
>>>>>>> > <https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>>>>>> > 
>>>>>>> >     PS: we should also agree that a "stable" extension should not
>>>>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>>>>> >     library support for an extension must move into `base`.
>>>>>>> > 
>>>>>>> > 
>>>>>>> > This seems like a good idea, however I still remain that _experimental_ 
>>>>>>> > features should not be on-by-default in a stable compiler. Yes, ideally 
>>>>>>> > I'd not even see them in a stable compiler, but I know this view is 
>>>>>>> > contentious. The use of `ghc-experimental` should therefore be guarded 
>>>>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in to 
>>>>>>> > experimental features.
>>>>>>> > 
>>>>>>> 
>>>>>>> -- 
>>>>>>> Adam Gundry, Haskell Consultant
>>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>>> 
>>>>>>> Registered in England & Wales, OC335890
>>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
> _______________________________________________
> 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/20230929/9f274006/attachment-0001.html>

From simon.peytonjones at gmail.com  Fri Sep 29 09:52:46 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 29 Sep 2023 10:52:46 +0100
Subject: [ghc-steering-committee] Stability
In-Reply-To: <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
References: <CAJKmMz9Zmc61dJU2ZXU0SoZeAMXEofTzNrtbE2O8uTNO-0x5dw@mail.gmail.com>
 <57f93b33-805c-241b-7e79-73bf9b5ce9a6@well-typed.com>
 <CAKfdd-zYsumfD7QRrzXzq9QaNkHRGPFSw_0=pdK38oi-O1vd2A@mail.gmail.com>
 <CAJKmMz_vDGixgYoOKMTetAKe5B6_5jYQcoC4-CLO3mO8ur7ZKA@mail.gmail.com>
 <CAKfdd-y_7t19s_i3o81RLb22CdCNgCDfUV09jZyH4APedbLa+A@mail.gmail.com>
 <CAJKmMz9W6ZKagfd1Li6AxCkrj5RZYtwPj9fwb2SKU2MsF3kSVQ@mail.gmail.com>
 <CAKfdd-zmCe2JxdmiDxgTn=8S4_aXhcFjugtRhFmTL9YZe_2KoA@mail.gmail.com>
Message-ID: <CAJKmMz_D3XEVZL4FtB6H1BRsCXEtQ8WS-nnQrQR8feCiCZTvig@mail.gmail.com>

>
> Thank you for bringing us this far. I'd be happy to step up to drive this
> further.
>

Thank you Moritz, that would be very helpful.  I see the steps (*not *in
dependency order) including

   - Develop stability ideas for Template Haskell.  I think we have agreed
   that it's a tricky case: widely used, but hard to stabilise
   - Develop a preliminary classification of language extensions, in
   partnership with the folk (who include Adam) working on the extension
   life cycle proposal
   <https://github.com/ghc-proposals/ghc-proposals/pull/601>.  The preliminary
   spreadsheet
   <https://docs.google.com/spreadsheets/d/1sRIcNKdflX2ogrx2EF3vKOn0vmv-UEOdladBqtYXdaw/edit#gid=0>is
   helpful -- thank you Adam. Let's not duplicate this work!
   - Ditto for "experimental features".
   - Turn the Google doc into a GHC Proposal.

I see all this as the GHC counterpart to the GHC base-library proposal
<https://github.com/haskellfoundation/tech-proposals/blob/main/proposals/accepted/051-ghc-base-libraries.rst>:
our general goal is to make a clear boundary between "stable" and
"experimental", so that:

   - users know when they are moving into experimental land
   - developers know when they risk breaking stable code

While the boundary is unclear, misunderstandings arise in both directions.

Simon

On Thu, 28 Sept 2023 at 13:39, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Simon,
>
> Thank you for bringing us this far. I'd be happy to step up to drive this
> further.
>
> I will say that I do see the tension you see as well. And I do believe if
> we come to a conclusion on this stability policy that it will
> make GHC development more rigorous, which I think is a good thing for all
> of us, not just the consumers of the compiler. I think
> we need to stay mindful that we can still freely experiment on the
> --std=experimental (or however that flag ends up being named)
> side. I see this whole discussion as leading us towards the
> language research reactor side of GHC being primarily confined behind
> --std=experimental, and the stability seeking (commercial application?) on
> the other side.
>
> I do not yet see how we can end up with the inability to change. We will
> just have a clearer process for _breaking_ changes. This
> does absolutely not mean we have to end up in a local optimum, or that we
> can not change. We can!
>
> Unless someone speaks up who does _not_ want me to drive, this, I'm happy
> to start driving this discussion (including writing the
> proposals, starting next week).
>
> Best,
>  Moritz
>
> On Thu, 28 Sept 2023 at 19:30, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Should we have a document (or better spreadsheet?) with a bullet point
>>> for each experimental feature to be considered? I believe we need to take
>>> into account that we can’t end up classifying most of todays Haskell
>>> programs unstable. As such I’d like to propose that we’d add to each
>>> features a counter for how much of hackage (as a proxy for real world
>>> usage) uses the specific feature.
>>>
>>
>> I think that would be a helpful way to "ground" the discussion a bit
>> more.  (The spreadsheet should also give a preliminary classification of
>> extensions, at least into stable/experimental.)
>>
>> I'm running out of capacity to drive this debate, useful though it is.
>> Does anyone else feel able to drive some of the legwork?
>>
>> So far this is all informal committee discussion.  The next step would be
>> a GHC Proposal inviting broader feedback from the community.  I'm just
>> hoping that by debugging it between ourselves we can side-step some
>> unproductive discussions in that bigger context.
>>
>> I believe we need to take into account that we can’t end up classifying
>>> most of todays Haskell programs unstable
>>>
>>
>> There is a tension here.  If we say something is "stable" then we have to
>> be super-careful about changing it.  (That's the whole point.)  And yet if
>> the feature (like INCOHERENT) is a flaky "you are on your own"
>> unsafePerformIO-like feature, I am axious about tying ourselves into an
>> inability to change the behaviour of corner cases.  I'm not sure how to
>> resolve this tension.
>>
>> Simon
>>
>>
>>
>> On Thu, 28 Sept 2023 at 02:20, Moritz Angermann <
>> moritz.angermann at gmail.com> wrote:
>>
>>> I think we are moving in the right direction! I do see however the
>>> tension rising on (2). And without being clear about (2), I don’t think we
>>> can properly agree on (1). We can agree on (1) in principle, but we need to
>>> clarify what we consider unstable/experimental, as a precondition to have
>>> finale agreement on (1). Otherwise people might agree to (1), only to be
>>> surprised by (2). For (3), I’d be happy to try to get my employer to
>>> provide resources for the implementation of —std=experimental.
>>>
>>> Thusly I believe we should start to build a list of features we consider
>>> sufficiently experimental that they should preclude an existing Haskell
>>> program from being considered stable. This list for me contains so far:
>>>
>>> - Linear Types
>>> - Dependent Haskell
>>>
>>> Adam pointed out experimental backend and non-tire-1 platforms. I tend
>>> to agree with this, but see this distinctly separate from the language
>>> stability (outside of backend specific language extensions, e.g. JSFFI).
>>>
>>> Platforms/backends may be experimental but those are (safe for specific
>>> lang exts) orthogonal to the Haskell code the compiler accepts.
>>>
>>> Should we have a document (or better spreadsheet?) with a bullet point
>>> for each experimental feature to be considered? I believe we need to take
>>> into account that we can’t end up classifying most of todays Haskell
>>> programs unstable. As such I’d like to propose that we’d add to each
>>> features a counter for how much of hackage (as a proxy for real world
>>> usage) uses the specific feature.
>>>
>>> Best,
>>>  Moritz
>>>
>>> On Wed, 27 Sep 2023 at 10:35 PM, Simon Peyton Jones <
>>> simon.peytonjones at gmail.com> wrote:
>>>
>>>> it's essential that we continue to have these discussions to ensure
>>>>> we're making the best decisions for the project and our community.
>>>>>
>>>>
>>>> Yes exactly!  Its tricky and nuanced; hence trying to articulate
>>>> something in a concrete doc, so we are all on the same page (literally!).
>>>>
>>>> However, deprecation cycles don't mean we're averse to major changes.
>>>>> It means we introduce them responsibly. When we believe a superior design
>>>>> is possible, we can start a deprecation process to transition towards it.
>>>>>
>>>>
>>>> I have tried to make this explicit in Section 4.   See what you think.
>>>>
>>>> I think there are three phases
>>>>
>>>>    1. Agree this document.  Is it what we want.
>>>>    2. Categorise extensions into stable/experimental, and identify
>>>>    experimental language features.
>>>>    3. Implement --std=experimental (Section 6).
>>>>
>>>> (1) is what we are doing now.  (2) will be some work, done by us.  (3)
>>>> is a larger task: it will require significant work to implement, and may
>>>> impose unwelcome churn of its own.  But that should not stop us doing (1)
>>>> and (2).
>>>>
>>>> Simon
>>>>
>>>>    -
>>>>
>>>>
>>>> On Wed, 27 Sept 2023 at 10:20, Moritz Angermann <
>>>> moritz.angermann at gmail.com> wrote:
>>>>
>>>>> Dear Adam,
>>>>>
>>>>> Thank you for your thoughtful feedback. I understand your
>>>>> reservations, and it's essential that we continue to have these discussions
>>>>> to ensure we're making the best decisions for the project and our
>>>>> community. Let me address each of your points in turn:
>>>>> - Cognitive Overhead for Users:
>>>>> I understand the concern about cognitive overhead due to the inability
>>>>> to remove complexity. However, our primary intention is to ensure a gradual
>>>>> transition for our users rather than abrupt shifts. Introducing changes via
>>>>> deprecation cycles allows users to adjust to modifications over time,
>>>>> reducing the immediate cognitive load. It's a balance between stability and
>>>>> simplicity, and I believe this approach allows us still to reduce
>>>>> complexity.
>>>>>
>>>>> - Maintenance Burden in the Compiler:
>>>>> Maintaining backward compatibility does indeed introduce some
>>>>> overhead. Still, it also encourages a more disciplined and considered
>>>>> approach to changes. With our deprecation cycles in place, it's not that we
>>>>> never remove complexity; rather, we do it in a way that provides ample time
>>>>> for adjustments. This benefits both the development team and the community.
>>>>>
>>>>> - Risk of Local Optimum:
>>>>> This is a valid concern. However, deprecation cycles don't mean we're
>>>>> averse to major changes. It means we introduce them responsibly. When we
>>>>> believe a superior design is possible, we can start a deprecation process
>>>>> to transition towards it. The flexibility and duration of our deprecation
>>>>> cycles can be tailored depending on the severity of the breaking change.
>>>>>
>>>>> - Discouraging Volunteer Contributors:
>>>>> I understand that lengthy approval processes can be off-putting. But
>>>>> it's crucial to note that a rigorous process ensures the consistency and
>>>>> reliability of our project. We always welcome and value contributions.
>>>>> Moreover, I believe this stability policy will provide us with clear
>>>>> guardrails on how changes can be contributed.
>>>>>
>>>>> I will not disagree on the costs. I do believe though that the costs
>>>>> for _breaking_ changes in the compiler ought to be borne by the people
>>>>> making the change, instead of those who use the compiler (and may not even
>>>>> benefit of those changes that caused breakage). I also see the team
>>>>> maintaining GHC as the one to enforce this; they are the ones who cut the
>>>>> releases. The fact that we may have breaking changes due to _bugs_ is
>>>>> covered explicitly in the stability policy document.
>>>>>
>>>>> With my CLC hat on, I have been focusing on the same stability
>>>>> guidelines as well (if it breaks existing code, I have been against those
>>>>> changes without deprecation policies). The issues with the
>>>>> template-haskell, and ghc library are noted. For the ghc library the
>>>>> question will remain if we intent to provide a stable api to the compiler
>>>>> or not. I believe many tools would like to have one, and if we relegate
>>>>> anything unstable to ghc-experimental this might be achieved. For
>>>>> template-haskell this is a bigger concern. Maybe we can collectively come
>>>>> up with a solution that would allow us to provide a more insulated template
>>>>> haskell interface from the compiler.
>>>>>
>>>>> However for template-haskell we might also need to look at what
>>>>> exactly caused those breaking changes in the past.
>>>>>
>>>>> What this document outlines (in my understanding) is that any
>>>>> experimental feature development can _only_ be visible behind
>>>>> --std=experimental, and the dependency of ghc-experimental. Unless those
>>>>> are given, the compiler should accept existing programs. This should allow
>>>>> us enough room to innovate (everyone is always free to opt-in to bleeding
>>>>> edge features with --std=experimental).  I also believe that most of what
>>>>> we have today will need to be treated as non-experimental simply because we
>>>>> did not have that mechanism before. We don't want to break existing
>>>>> programs as much as possible, thus relegating existing features into
>>>>> --std=experimental (except for some fairly clear ones: e.g. Dependent
>>>>> Haskell, and Linear Types?) is not really possible. What we can however do
>>>>> is start deprecation phases for a few versions, moving features we consider
>>>>> highly experimental (or maybe even bad) into `--std=experimental`. Just by
>>>>> having deprecation phases and given the ecosystem enough time to adjust
>>>>> (and provide feedback) we might come to different conclusions.
>>>>>
>>>>> As I've also outlined in the document, _if_ GHC was trivially
>>>>> swappable, companies like IOG would _love_ to try new compilers and report
>>>>> back bugs and regressions. As it is today, we can't. Making a large live
>>>>> codebase compatible with 9.8 is a multiple weeks effort. Experimenting with
>>>>> nightlies is technically impossible. _If_ I could setup the built of our
>>>>> software trivial with ghc nightlies, I'd be _happy_ to build the
>>>>> infrastructure out it to provide performance regressions (compilation,
>>>>> runtime, ...) for our codebase and provide the feedback to the GHC team;
>>>>> however I can't. And thus I'm stuck patching and fixing 8.10, and 9.2
>>>>> today. 9.6 maybe soon, but likely at the point in time where 9.6 is not
>>>>> going to see any further releases, so I can spare trying to even forward
>>>>> port my patches to HEAD. Not that I could even test them with head
>>>>> properly, as our source is not accepted by HEAD. Thus I end up writing
>>>>> patches against old stale branches. This to me is a fairly big
>>>>> discouragement from contributing to GHC.
>>>>>
>>>>> Best,
>>>>>  Moritz
>>>>>
>>>>> On Mon, 25 Sept 2023 at 15:17, Adam Gundry <adam at well-typed.com>
>>>>> wrote:
>>>>>
>>>>>> I'm afraid that I'm somewhat sceptical of this approach.
>>>>>>
>>>>>> A strong stability guarantee is certainly a valuable goal, but it
>>>>>> also
>>>>>> comes with costs, which I'd like to see more clearly articulated.
>>>>>> Some
>>>>>> of them include:
>>>>>>
>>>>>>   * Cognitive overhead for users, because of the inability to remove
>>>>>> complexity from the design.
>>>>>>
>>>>>>   * Increasing maintenance burden in the compiler, because of the
>>>>>> additional work needed to implement new features and the inability to
>>>>>> remove complexity from the implementation.
>>>>>>
>>>>>>   * A risk of getting stuck in a local optimum, because moving to a
>>>>>> better design would entail breaking changes.
>>>>>>
>>>>>>   * Discouraging volunteer contributors, who are much less likely to
>>>>>> work on a potentially beneficial change if the process for getting it
>>>>>> approved is too onerous. (I'm worried we're already reaching that
>>>>>> point
>>>>>> due to the increasing burden of well-intentioned processes.)
>>>>>>
>>>>>> Ultimately every proposed change has a cost-benefit trade-off, with
>>>>>> risk
>>>>>> of breakage being one of the costs. We need to consciously evaluate
>>>>>> that
>>>>>> trade-off on a case-by-case basis. Almost all changes might break
>>>>>> something (e.g. by regressing performance, or for Hyrum's Law
>>>>>> reasons),
>>>>>> so there needs to be a proportionate assessment of how likely each
>>>>>> change is to be damaging in practice, bearing in mind that such an
>>>>>> assessment is itself costly and limited in scope.
>>>>>>
>>>>>> It seems to me that the GHC team have taken on board lessons
>>>>>> regarding
>>>>>> stability of the language, and the extension system already gives
>>>>>> quite
>>>>>> a lot of flexibility to evolve the language in a backwards-compatible
>>>>>> way. In my experience, the key stability problems preventing upgrades
>>>>>> to
>>>>>> recent GHC releases are:
>>>>>>
>>>>>>   * The cascading effect of breaking changes in one library causing
>>>>>> the
>>>>>> need to upgrade libraries which depend upon it. This is primarily
>>>>>> under
>>>>>> the control of the CLC and library maintainers, however, not the GHC
>>>>>> team. It would help if base was minimal and reinstallable, but that
>>>>>> isn't a total solution either, because you'd still have to worry
>>>>>> about
>>>>>> packages depending on template-haskell or the ghc package itself.
>>>>>>
>>>>>>   * Performance regressions or critical bugs. These tend to be a
>>>>>> significant obstacle to upgrading for smaller commercial users. But
>>>>>> spending more of our limited resources on stability of the language
>>>>>> means fewer resources for resolving these issues.
>>>>>>
>>>>>> There's surely more we can do here, but let's be careful not to pay
>>>>>> too
>>>>>> many costs to achieve stability of the *language* alone, when
>>>>>> stability
>>>>>> of the *libraries* and *implementation* are both more important and
>>>>>> harder to fix.
>>>>>>
>>>>>> Adam
>>>>>>
>>>>>>
>>>>>> On 22/09/2023 10:53, Simon Peyton Jones wrote:
>>>>>> > Dear GHC SC
>>>>>> >
>>>>>> > To avoid derailing the debate about -Wsevere
>>>>>> > <
>>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003407.html>,
>>>>>> and HasField redesign <
>>>>>> https://mail.haskell.org/pipermail/ghc-steering-committee/2023-September/003383.html>,
>>>>>> I'm starting a new (email for now) thread about stability.
>>>>>> >
>>>>>> > I have tried to articulate what I believe is an evolving consensus
>>>>>> in
>>>>>> > this document
>>>>>> > <
>>>>>> https://docs.google.com/document/d/1wtbAK6cUhiAmM6eHV5TLh8azEdNtsmGwm47ZulgaZds/edit?usp=sharing
>>>>>> >.
>>>>>> >
>>>>>> > If we converge, we'll turn that into a proper PR for the GHC
>>>>>> proposal
>>>>>> > process, although it has wider implications than just GHC proposals
>>>>>> and
>>>>>> > we should share with a broader audience.  But let's start with the
>>>>>> > steering committee.
>>>>>> >
>>>>>> > Any views?  You all have edit rights.
>>>>>> >
>>>>>> > I think that the draft covers Moritz's and Julian's goals, at least
>>>>>> that
>>>>>> > was my intention.  I have pasted Moritz's last email below, for
>>>>>> context.
>>>>>> >
>>>>>> > Simon
>>>>>> >
>>>>>> >
>>>>>> > ========= Moritz's last email ============
>>>>>> >
>>>>>> > Now, this is derailing the original discussion a bit, and I'm not
>>>>>> sure
>>>>>> > how far we want to take this. But, regarding @Simon Marlow
>>>>>> > <mailto:marlowsd at gmail.com>'s comment
>>>>>> >
>>>>>> >     This is one cultural aspect of our community I'd like to shift:
>>>>>> the
>>>>>> >     expectation that it's OK to make breaking changes as long as you
>>>>>> >     warn about
>>>>>> >     them or go through a migration cycle. It just isn't! (and I
>>>>>> speak as
>>>>>> >     someone who used to make lots of changes, I'm now fully
>>>>>> repentant!).
>>>>>> >     That's
>>>>>> >     not to say that we shouldn't ever change anything, but when
>>>>>> >     considering the
>>>>>> >     cost/benefit tradeoff adding a migration cycle doesn't reduce
>>>>>> the
>>>>>> >     cost, it
>>>>>> >     just defers it.
>>>>>> >
>>>>>> >
>>>>>> > I actually read this as we should stop having breaking changes to
>>>>>> begin
>>>>>> > with. And _if_ we
>>>>>> > do have breaking changes, that deprecation does not change the need
>>>>>> to
>>>>>> > actually change
>>>>>> > code (cost). As outlined in my reply to that, and @Richard
>>>>>> Eisenberg
>>>>>> > <mailto:lists at richarde.dev>'s observation, it
>>>>>> > "smears" the cost. The--to me--_much_ bigger implication of
>>>>>> deprecation
>>>>>> > cycles is that we
>>>>>> > _inform_ our _customers_ about upcoming changes _early_, instead of
>>>>>> > _after the fact_. We
>>>>>> > also give them ample time to react. Being by changing their code,
>>>>>> or
>>>>>> > raising their concerns.
>>>>>> > Would the Simplified Subsumptions / Deep Subsumptions change
>>>>>> have looked
>>>>>> > differently?
>>>>>> > As such I see deprecation cycles as orthogonal to the question if
>>>>>> we
>>>>>> > should have breaking
>>>>>> > changes to begin with.
>>>>>> >
>>>>>> > Thus I believe the following:
>>>>>> >
>>>>>> >     - Do have a deprecation cycle if possible.
>>>>>> >     - Do not treat a deprecation cycle as an excuse.  Costs are
>>>>>> deferred
>>>>>> >     but are as large as ever.
>>>>>> >
>>>>>> >
>>>>>> > should be upgraded to:
>>>>>> > - Preferably _no_ breaking changes.
>>>>>> > - If breaking changes, then with a deprecation cycle, unless
>>>>>> technically
>>>>>> > infeasible.
>>>>>> > - An understanding that any breaking change incurs significant
>>>>>> costs.
>>>>>> >
>>>>>> > Ocaml recently added multicore support, and they put tremendous
>>>>>> effort
>>>>>> > into making
>>>>>> > sure it keeps backwards compatibility:
>>>>>> > https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md
>>>>>> > <
>>>>>> https://github.com/ocaml-multicore/docs/blob/main/ocaml_5_design.md>
>>>>>> >
>>>>>> >     PS: we should also agree that a "stable" extension should not
>>>>>> >     require dependencies on ghc-experimental.  To become stable, any
>>>>>> >     library support for an extension must move into `base`.
>>>>>> >
>>>>>> >
>>>>>> > This seems like a good idea, however I still remain that
>>>>>> _experimental_
>>>>>> > features should not be on-by-default in a stable compiler. Yes,
>>>>>> ideally
>>>>>> > I'd not even see them in a stable compiler, but I know this view is
>>>>>> > contentious. The use of `ghc-experimental` should therefore be
>>>>>> guarded
>>>>>> > by `--std=experimental` as Julian suggested. That is a loud opt-in
>>>>>> to
>>>>>> > experimental features.
>>>>>> >
>>>>>>
>>>>>> --
>>>>>> Adam Gundry, Haskell Consultant
>>>>>> Well-Typed LLP, https://www.well-typed.com/
>>>>>>
>>>>>> Registered in England & Wales, OC335890
>>>>>> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>>> <https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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/20230929/212f62a5/attachment-0001.html>

From chris at chrisdornan.com  Fri Sep 29 11:47:17 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Fri, 29 Sep 2023 12:47:17 +0100
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
Message-ID: <54C921C0-44B1-497C-981D-16BE688CBE6B@chrisdornan.com>

All,

This proposal has now been revised to make it non-disruptive. 

That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal.

Chris


> On 8 Sep 2023, at 11:57, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> Author: Sebastian Graf, David Knothe
> Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> Recommendation: Acceptance
> 
> ## Summary
> 
> This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.
> 
> The syntax of the old proposal,
> 
> ```haskell
>     stringOfT :: T -> Maybe String
>     stringOfT (T1 s)              = Just s
>     stringOfT (one of T2{}, T3{}) = Nothing
> ```
> 
> is replaced with
> 
> ```haskell
>     stringOfT :: T -> Maybe String
>     stringOfT (T1 s)       = Just s
>     stringOfT (T2{}; T3{}) = Nothing
> ```
> 
> or indeed
> 
> ```haskell
>     stringOfT :: T -> Maybe String
>     stringOfT x = case x of
>       T1 s -> Just s
>       T2{}
>       T3{} -> Nothing
> ```
> 
> (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)
> 
> The authors have conducted polls to see what folks preferred, landing on this proposal. The
> adjustments to the Haskell grammar are really quite minimal requiring one extra production.
> 
> ## Recommendation
> 
> The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend
> that we accept it
> 

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

From moritz.angermann at gmail.com  Fri Sep 29 12:46:57 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Fri, 29 Sep 2023 20:46:57 +0800
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <54C921C0-44B1-497C-981D-16BE688CBE6B@chrisdornan.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <54C921C0-44B1-497C-981D-16BE688CBE6B@chrisdornan.com>
Message-ID: <CAKfdd-wf3Zj8_rZpPhPq2to-vDs_dRiQw54S6CzbvZK2DSda6w@mail.gmail.com>

Sounds good to me.

On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan <chris at chrisdornan.com> wrote:

> All,
>
> This proposal has now been revised to make it non-disruptive.
>
> That was the only issue of substance that surfaced in our discussion and I
> recommend that we accept this revised proposal.
>
> Chris
>
>
> On 8 Sep 2023, at 11:57, Chris Dornan <chris at chrisdornan.com> wrote:
>
> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
> Author: Sebastian Graf, David Knothe
> Rendered proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
> Recommendation: Acceptance
>
> ## Summary
>
> This proposal refines the syntax of an already accpted proposal (#522) for
> writing or patterns.
>
> The syntax of the old proposal,
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (one of T2{}, T3{}) = Nothing
> ```
>
> is replaced with
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT (T1 s) = Just s
> stringOfT (T2{}; T3{}) = Nothing
> ```
>
> or indeed
>
> ```haskell
> stringOfT :: T -> Maybe String
> stringOfT x = case x of
> T1 s -> Just s
> T2{}
> T3{} -> Nothing
> ```
>
> (Beacuse the '(' ... ')' are optional here, we can remove them and
> naturally exploit layout.)
>
> The authors have conducted polls to see what folks preferred, landing on
> this proposal. The
> adjustments to the Haskell grammar are really quite minimal requiring one
> extra production.
>
> ## Recommendation
>
> The proposal is nondiruptive and as a whole addresses an important
> practical topic. I recommend
> that we accept it
>
>
> _______________________________________________
> 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/20230929/93a59f42/attachment.html>

From adam at well-typed.com  Fri Sep 29 18:41:11 2023
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 29 Sep 2023 19:41:11 +0100
Subject: [ghc-steering-committee] #571: -Wsevere,
 Shepherd: Adam (rec: accept)
In-Reply-To: <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
References: <65c0dcdc15b2a8ba997e0b6318af66937c1226f4.camel@joachim-breitner.de>
 <592b0fff-1674-8f36-fe02-80a1bcfdf2b7@well-typed.com>
Message-ID: <4d6fb3aa-e8d2-a198-8e65-76f4d9a8354e@well-typed.com>

Dear Committee,

It seems we are somewhat split on the -Wsevere proposal, even assuming 
it is introduced with a deprecation period (changing the warning text 
and adding the group in advance). There is consensus that adding the 
group by itself is fine, and potentially enabling -Werror=severe under 
GHC2024, but enabling it by default for existing code is more controversial.

Ultimately this is a judgement call about the value of the proposal 
versus the breakage it causes. I remain of the view that it is 
worthwhile. This is not merely about more aggressively enforcing best 
practice. Rather, it eliminates the risk of the following:

* Suppose package A defines a type class, package B depends on package 
A, and package C depends on package B.

* Now package A extends the type class definition with a new method and 
default methods. Everything still compiles; package B now issues a 
-Wmissing-methods warning (but is not actively maintained, and the 
author of package C is unlikely to look at warnings in all their 
dependencies).

* Users of package C have to try to debug an infinite loop.

Given that this change avoids a significant issue, affected code has 
been issuing warnings for many years, and impacted users can very easily 
set -Wwarn=severe either at the package level or the project level, I 
think is worth accepting the backwards compatibility cost and the fact 
that some Haskell2010 code will no longer be accepted by default.

Matt Parsons puts it well in the CLC thread, which is pretty clearly in 
favour of this proposal overall 
(https://github.com/haskell/core-libraries-committee/issues/207#issuecomment-1726091889):

 > I think GHC should strive to make fewer breaking changes, and make 
those changes as easy-to-adopt as possible. But this is not a question 
of GHC breaking things, but rather revealing and providing 
early-diagnosis for already broken things.

Further opinions are welcome, of course.

Adam


On 14/09/2023 09:32, Adam Gundry wrote:
> Dear Committee,
> 
> Joachim, along with Oleg Grenrus, proposes to change -Wmissing-methods 
> and -Wmissing-fields warnings into errors by default (retaining the 
> option to downgrade them). I recommend we accept the proposal.
> 
> Proposal: https://github.com/ghc-proposals/ghc-proposals/pull/571
> Rendered: 
> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
> 
> This is primarily motivated by the fact that when classes have default 
> methods, missing methods can lead to runtime loops, which are generally 
> difficult to debug. Since in practice not all users pay attention to 
> warnings that do not inhibit compilation, it makes sense to identify a 
> class of warnings that are sufficiently serious to require explicit 
> action from the user to silence them.
> 
> Since these warnings are currently not errors by default, library 
> authors experimentally assessing the impact of changes may be lead to 
> assume that introducing new methods/fields does not lead to breakage 
> (because downstream code will still compile). The proposal thus makes it 
> more obvious that adding a new method or field is a breaking change.
> 
> The proposal deliberately causes builds to fail by default for some 
> libraries that currently emit warnings. Oleg has kindly performed impact 
> assessments to identify such libraries, and the breakage of a few 
> packages seems worth the cost.
> 
> It is easy to restore the warnings to their previous classification by 
> passing an option at build time, e.g. using -Wno-error=missing-methods. 
> Users can set such an option in cabal.project or stack.yaml to work 
> around breakage that is not promptly fixed by the library author.
> 
> This change does mean that GHC with -XHaskell98/2010 will by default 
> reject some programs that are explicitly permitted by the Haskell98/2010 
> specification. I recommend we document this infelicity, but accept it, 
> as much of the benefit of the proposal is that it applies by default.
> 
> The proposal establishes the precedent that some warnings may be treated 
> as errors by default, and introduces a warning group -Wsevere to 
> classify them. This seems conceptually useful and gives us the option to 
> extend the -Wsevere set in the future (e.g. as a final stage of 
> deprecation before a feature is removed).
> 
> Thoughts?
> 
> Adam
> 
> 
> On 11/09/2023 20:25, Joachim Breitner wrote:
>> Dear Committee,
>>
>> based on suggestions by Oleg Grenrus, I wrote a proposal to introduce a
>> warning group -Wsevere for on-by-defaults, error-by-default warnings,
>> and initially fill it with missing-methods and missing-fields.
>>
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/571
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/wsevere/proposals/0000-severe-warnings.rst
>>
>> I’d like to nominate Adam as the shepherd, who already reviewed it a
>> bit on Github.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>>
>> Cheers,
>> Joachim


-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England


From eric at seidel.io  Sat Sep 30 17:32:31 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 30 Sep 2023 13:32:31 -0400
Subject: [ghc-steering-committee] Amend or patterns (#522) to use p1 ;
	p2 (#609)
In-Reply-To: <CAKfdd-wf3Zj8_rZpPhPq2to-vDs_dRiQw54S6CzbvZK2DSda6w@mail.gmail.com>
References: <CABSB5jURWMW+nR8EHFAY-v5xmeFuctr1gSBkB6tV9QSBhjZt5Q@mail.gmail.com>
 <54C921C0-44B1-497C-981D-16BE688CBE6B@chrisdornan.com>
 <CAKfdd-wf3Zj8_rZpPhPq2to-vDs_dRiQw54S6CzbvZK2DSda6w@mail.gmail.com>
Message-ID: <c1f8e93e-6996-40e9-ad86-16a451e95568@app.fastmail.com>

I'm happy with this change.

On Fri, Sep 29, 2023, at 08:46, Moritz Angermann wrote:
> Sounds good to me. 
>
> On Fri, 29 Sep 2023 at 7:47 PM, Chris Dornan <chris at chrisdornan.com> wrote:
>> All,
>> 
>> This proposal has now been revised to make it non-disruptive. 
>> 
>> That was the only issue of substance that surfaced in our discussion and I recommend that we accept this revised proposal.
>> 
>> Chris
>> 
>> 
>>> On 8 Sep 2023, at 11:57, Chris Dornan <chris at chrisdornan.com> wrote:
>>> 
>>> Proposal: Amend or patterns (#522) to use p1 ; p2 (#609)
>>> Author: Sebastian Graf, David Knothe
>>> Rendered proposal: https://github.com/ghc-proposals/ghc-proposals/blob/eb4b67c29282520b2c5c6a49c3047dbecb15dde1/proposals/0522-or-patterns.rst
>>> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/609
>>> Recommendation: Acceptance
>>> 
>>> ## Summary
>>> 
>>> This proposal refines the syntax of an already accpted proposal (#522) for writing or patterns.
>>> 
>>> The syntax of the old proposal,
>>> 
>>> ```haskell
>>> stringOfT :: T -> Maybe String
>>> stringOfT (T1 s) = Just s
>>> stringOfT (one of T2{}, T3{}) = Nothing
>>> ```
>>> 
>>> is replaced with
>>> 
>>> ```haskell
>>> stringOfT :: T -> Maybe String
>>> stringOfT (T1 s) = Just s
>>> stringOfT (T2{}; T3{}) = Nothing
>>> ```
>>> 
>>> or indeed
>>> 
>>> ```haskell
>>> stringOfT :: T -> Maybe String
>>> stringOfT x = case x of
>>> T1 s -> Just s
>>> T2{}
>>> T3{} -> Nothing
>>> ```
>>> 
>>> (Beacuse the '(' ... ')' are optional here, we can remove them and naturally exploit layout.)
>>> 
>>> The authors have conducted polls to see what folks preferred, landing on this proposal. The
>>> adjustments to the Haskell grammar are really quite minimal requiring one extra production.
>>> 
>>> ## Recommendation
>>> 
>>> The proposal is nondiruptive and as a whole addresses an important practical topic. I recommend
>>> that we accept it
>>> 
>> 
>> _______________________________________________
>> 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 30 17:55:48 2023
From: eric at seidel.io (Eric Seidel)
Date: Sat, 30 Sep 2023 13:55:48 -0400
Subject: [ghc-steering-committee] #526: Applicative Comprehensions
	(rec:accept)
In-Reply-To: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
Message-ID: <34e43a8b-2525-4931-9d25-95386be1068f@app.fastmail.com>

I'm on the fence about this one. I can see the utility, sure, but we've also been talking a lot about stability of extensions lately. One question I asked myself while reading the proposal is whether I would support including this extension (or MonadComprehensions) in the next GHC20XX. I'm not sure but my gut reaction is probably not.

On Thu, Sep 28, 2023, at 03:12, Simon Marlow wrote:
> Dear committee,
>
> #526 proposes a new extension ApplicativeComprehensions (implying 
> MonadComprehensions). It would provide the equivalent of the current 
> ApplicativeDo desugaring for do-expressions to list comprehensions.
>  • Github thread 
> <https://github.com/ghc-proposals/ghc-proposals/pull/526>
>  • Rendered 
> <https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst>
> The extension itself is relatively uncontroversial, but there are some 
> unresolved quirks in the original ApplicativeDo extension which made us 
> uneasy about extending it. However, after various discussions I'm going 
> to propose accepting this proposal in its current state.  Rationale:
>  • It doesn't make things worse, and the implementation isn't likely to 
> add significant complexity.
>  • It retains consistency between ApplicativeDo and 
> ApplicativeComprehensions (in contrast to the idea of making 
> ApplicativeComprehensions perform a simpler desugaring, which came up 
> during the discussion)
>  • A future proposal can add a simpler version of the desugaring for 
> both extensions later.
>
> Cheers
> Simon
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From marlowsd at gmail.com  Sat Sep 30 18:31:45 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Sat, 30 Sep 2023 19:31:45 +0100
Subject: [ghc-steering-committee] #526: Applicative Comprehensions
	(rec:accept)
In-Reply-To: <34e43a8b-2525-4931-9d25-95386be1068f@app.fastmail.com>
References: <CANsrgPJJrLVC+Yz=57JWfqoX_iapRG=FRBkGAASzusS-8a7ZYg@mail.gmail.com>
 <34e43a8b-2525-4931-9d25-95386be1068f@app.fastmail.com>
Message-ID: <CANsrgPJz+OZMy1T5QoVmKT8aiC9dFzbiuPfz771zK+=vgN2VbA@mail.gmail.com>

We certainly wouldn't want to include either ApplicativeDo or
ApplicativeComprehensions in GHC20xx, indeed it was never the intention
that ApplicativeDo would be enabled by default. Perhaps the simpler
predictable form (yet to be proposed) could be in a future GHC20xx.

Cheers
Simon

On Sat, 30 Sept 2023 at 18:57, Eric Seidel <eric at seidel.io> wrote:

> I'm on the fence about this one. I can see the utility, sure, but we've
> also been talking a lot about stability of extensions lately. One question
> I asked myself while reading the proposal is whether I would support
> including this extension (or MonadComprehensions) in the next GHC20XX. I'm
> not sure but my gut reaction is probably not.
>
> On Thu, Sep 28, 2023, at 03:12, Simon Marlow wrote:
> > Dear committee,
> >
> > #526 proposes a new extension ApplicativeComprehensions (implying
> > MonadComprehensions). It would provide the equivalent of the current
> > ApplicativeDo desugaring for do-expressions to list comprehensions.
> >  • Github thread
> > <https://github.com/ghc-proposals/ghc-proposals/pull/526>
> >  • Rendered
> > <
> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
> >
> > The extension itself is relatively uncontroversial, but there are some
> > unresolved quirks in the original ApplicativeDo extension which made us
> > uneasy about extending it. However, after various discussions I'm going
> > to propose accepting this proposal in its current state.  Rationale:
> >  • It doesn't make things worse, and the implementation isn't likely to
> > add significant complexity.
> >  • It retains consistency between ApplicativeDo and
> > ApplicativeComprehensions (in contrast to the idea of making
> > ApplicativeComprehensions perform a simpler desugaring, which came up
> > during the discussion)
> >  • A future proposal can add a simpler version of the desugaring for
> > both extensions later.
> >
> > Cheers
> > Simon
> > _______________________________________________
> > 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/20230930/87a19182/attachment.html>