From mail at joachim-breitner.de  Sun Oct  2 11:50:42 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Oct 2022 13:50:42 +0200
Subject: [ghc-steering-committee] Please review #512: NoFieldSelectors as
 datatype annotation, New Shepherd: Vladislav
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <5ba89fe6c9cd4364df4bb838d26fe675ba8ed1a5.camel@joachim-breitner.de>

Hi,

Am Samstag, dem 03.09.2022 um 06:31 +0200 schrieb Joachim Breitner:
> Dear Committee,
> 
> NoFieldSelectors as datatype annotation
> have been proposed by Matt Parsons
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/512
> 
> https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scoped/proposals/0512-nofieldselectors-per-datatype.md
> 
> I suggest Baldur to shepherd this proposal.

given that Baldur stepped down, I suggest Vladislav to shepherd this.

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 mail at joachim-breitner.de  Sun Oct  2 11:54:24 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Oct 2022 13:54:24 +0200
Subject: [ghc-steering-committee] Call for nominations coming up
Message-ID: <25336c2d519d4142f36c9da0eca087fd1d70838c.camel@joachim-breitner.de>

Dear Committee,

with Baldurs resignation, we now have 8 non-expiring member (Arnaud’s
term has expired in July) and we ought to do a new call for
nominations. Arnaud is of course very welcome to re-nominate himself,
and I personally hope he will.

Do you have any suggestions for improvements to the process?
This is the mail I sent around last time – do you want to to change
anything there?
https://mail.haskell.org/pipermail/ghc-steering-committee/2022-January/002711.html

Should I maybe remove the paragraph asking for “conservative members”?

Also maybe think of people you’d personally like to nudge to apply.

Cheers,
Joachim




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


From mail at joachim-breitner.de  Sun Oct  2 11:59:29 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Oct 2022 13:59:29 +0200
Subject: [ghc-steering-committee] Please review #518: Type vs Constraint
 proposal, Shepherd: Eric
In-Reply-To: <48affc16-3726-4e97-b23e-c93f4521f5ec@app.fastmail.com>
References: <3923c3181ede270d8a37d0657550bac534af8676.camel@joachim-breitner.de>
 <50f03efe-cf2f-42e7-9d73-07da304cdd4b@www.fastmail.com>
 <CAJKmMz81921uPEe-7F5ABc8T1BKqLktdrV=Jaky3OrUbashuHg@mail.gmail.com>
 <1b0b4f01-58c4-45aa-88ae-092f119b3914@www.fastmail.com>
 <76b1c4b4aeeea7927ebaf190e3e2f4746adcc758.camel@joachim-breitner.de>
 <ca2d7175-2c99-4178-8343-3779e2021adc@www.fastmail.com>
 <010f018380af97e2-edb5d5b7-d9e3-4a96-90a9-f126913f01d4-000000@us-east-2.amazonses.com>
 <48affc16-3726-4e97-b23e-c93f4521f5ec@app.fastmail.com>
Message-ID: <f043a99c9544354534a5857a3a972e847bbea872.camel@joachim-breitner.de>

Done!

Am Dienstag, dem 27.09.2022 um 21:10 -0400 schrieb Eric Seidel:
> Thanks Richard!
> 
> Joachim, I think we're good to merge now!
> 
> On Tue, Sep 27, 2022, at 16:42, Richard Eisenberg wrote:
> > Yes, I'm fine here -- would still love to have this worked out, but I 
> > don't want to hold things up further.
> > 
> > Richard
> > 
> > > On Sep 17, 2022, at 11:33 AM, Eric Seidel <eric at seidel.io> wrote:
> > > 
> > > Richard, are you ok with this position? I think you were the only one with a lingering concern about the proposal.
> > > 
> > > On Mon, Sep 12, 2022, at 11:32, Joachim Breitner wrote:
> > > > Hi,
> > > > 
> > > > Am Montag, dem 12.09.2022 um 09:05 -0400 schrieb Eric Seidel:
> > > > > My view remains that the exact mechanism of public/internal
> > > > > separation does not need to be fleshed out in order to accept this
> > > > > proposal. It can be hashed out in parallel with the implementation.
> > > > 
> > > > I agree with that – the concerns are nicely separated this way.
> > > > 
> > > > Cheers,
> > > > Joachim
> > > > 
> > > > -- 
> > > > Joachim Breitner
> > > >  mail at joachim-breitner.de
> > > >  http://www.joachim-breitner.de/
> > > > 
> > > > _______________________________________________
> > > > ghc-steering-committee mailing list
> > > > ghc-steering-committee at haskell.org
> > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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 mail at joachim-breitner.de  Sun Oct  2 12:02:21 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 02 Oct 2022 14:02:21 +0200
Subject: [ghc-steering-committee] Please review #516: Introduce
 `-Wincomplete-record-selectors`, Shepherd: Eric
In-Reply-To: <979347a9-ba4b-4e6d-b3cf-057b80148f12@app.fastmail.com>
References: <5e616addb7390649422195311e6a70b7e5ee3306.camel@joachim-breitner.de>
 <35395b03-ba60-4d4d-8c40-f1bb66d8845a@www.fastmail.com>
 <CAH6fHQnEcntEakS-kbyL4di9iuGBrN8accoKAnBggNtRoYqDvw@mail.gmail.com>
 <010f018317bb28a3-296eb5a7-917e-4498-9aeb-a2ed21ccbd20-000000@us-east-2.amazonses.com>
 <CAJKmMz9SveR6DPRQYMuGdVf27BXf2B7CxHdaG4iz0eSmf_q=tQ@mail.gmail.com>
 <464b0a37-3132-4ed5-8e07-199ef4074590@www.fastmail.com>
 <B72F3D88-D9C5-4F0A-A7E0-17B4CCE9DCBE@chrisdornan.com>
 <CAJKmMz_UAdm6Q6PqLSTV325rEQDeU1Vw3tdH3sPUd-Bf3w6GLA@mail.gmail.com>
 <C6308354-EB18-4862-9EE6-7FE6B80F5174@chrisdornan.com>
 <979347a9-ba4b-4e6d-b3cf-057b80148f12@app.fastmail.com>
Message-ID: <02fd156775421b713f7a1f2546879d444ddc5585.camel@joachim-breitner.de>

And done

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

Hi,

Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:
> So given that we don’t have a consensus, I suggest to not spend more
> time on it, let’s reject it (and remember where it is to be revived, if
> and when the problem becomes more clearer visible).

no complaints about this either? I’ll mark it as rejected in a few days
unless someone shouts.

Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Mon Oct  3 08:28:26 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 3 Oct 2022 09:28:26 +0100
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <0729707b8b57649f6815646cd59adf95a8e7b385.camel@joachim-breitner.de>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
 <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
 <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>
 <57641e5d2c3e4f5f061579665713faa1120341f1.camel@joachim-breitner.de>
 <0729707b8b57649f6815646cd59adf95a8e7b385.camel@joachim-breitner.de>
Message-ID: <CAJKmMz-Q4K8kSyNuFnT08P+WaZcJ10Y70iWQioz7saYuoH7o0g@mail.gmail.com>

As you say, it's not that big a deal.  I'm content to reject for now.  I'm
sure we'll keep coming back to it!

Simon

On Sun, 2 Oct 2022 at 13:03, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:
> > So given that we don’t have a consensus, I suggest to not spend more
> > time on it, let’s reject it (and remember where it is to be revived, if
> > and when the problem becomes more clearer visible).
>
> no complaints about this either? I’ll mark it as rejected in a few days
> unless someone shouts.
>
> 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/20221003/31d9c78b/attachment.html>

From arnaud.spiwack at tweag.io  Mon Oct  3 08:28:00 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 3 Oct 2022 10:28:00 +0200
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <CAJKmMz-Q4K8kSyNuFnT08P+WaZcJ10Y70iWQioz7saYuoH7o0g@mail.gmail.com>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
 <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
 <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>
 <57641e5d2c3e4f5f061579665713faa1120341f1.camel@joachim-breitner.de>
 <0729707b8b57649f6815646cd59adf95a8e7b385.camel@joachim-breitner.de>
 <CAJKmMz-Q4K8kSyNuFnT08P+WaZcJ10Y70iWQioz7saYuoH7o0g@mail.gmail.com>
Message-ID: <CAH6fHQnq1VCB6dcLkk=AXot+E4Hn87s0eQbBTTFi3kxN68w62g@mail.gmail.com>

If we do come back to it, it's going to be stronger evidence that something
in that space is needed.

On Mon, Oct 3, 2022 at 10:26 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> As you say, it's not that big a deal.  I'm content to reject for now.  I'm
> sure we'll keep coming back to it!
>
> Simon
>
> On Sun, 2 Oct 2022 at 13:03, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:
>> > So given that we don’t have a consensus, I suggest to not spend more
>> > time on it, let’s reject it (and remember where it is to be revived, if
>> > and when the problem becomes more clearer visible).
>>
>> no complaints about this either? I’ll mark it as rejected in a few days
>> unless someone shouts.
>>
>> 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/20221003/e5f92ec6/attachment.html>

From simon.peytonjones at gmail.com  Mon Oct  3 08:37:15 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 3 Oct 2022 09:37:15 +0100
Subject: [ghc-steering-committee] Call for nominations coming up
In-Reply-To: <25336c2d519d4142f36c9da0eca087fd1d70838c.camel@joachim-breitner.de>
References: <25336c2d519d4142f36c9da0eca087fd1d70838c.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8a3-smjmUg+Ge071J54W2E8onDnwXfDMTMYFf-4Ww9Tg@mail.gmail.com>

Thanks for initiating this, Joachim.

I have made some small suggested adjustments, below.  (Needs a bit of
paragraph filling.)

Simon


Dear Haskell community,

the GHC Steering committee is seeking nominations for at least two new
members.

The committee scrutinizes, nitpicks, improves, weighs and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed. In
particular, please have a look at the bylaws at
   https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst


We are looking for a member who has the ability
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.


There is no shortage of people who are eager to get fancy new
features into the language, both in the committee and the wider
community. But each new feature imposes a cost, to implement, to maintain
in perpetuity in GHC's code base, to learn,
and to deal with its unexpected interaction with other features.
We need to strike a balance, one that encourages innovation (as GHC
always has) while still making Haskell attractive for real-world
production use and for teaching. We therefore seek a balance of
background, expertise, and views on the committee.

Membership of the committee gives you the chance to influence the future
direction of Haskell, and to serve the Haskell community.
The committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

To make a nomination, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de
<https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
until February 11th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

We explicitly encourage self-nominations. You can nominate others, but
please obtain their explicit consent to do so. (We don’t want to choose
someone who turns out to be unable to serve.)


On Sun, 2 Oct 2022 at 12:54, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> with Baldurs resignation, we now have 8 non-expiring member (Arnaud’s
> term has expired in July) and we ought to do a new call for
> nominations. Arnaud is of course very welcome to re-nominate himself,
> and I personally hope he will.
>
> Do you have any suggestions for improvements to the process?
> This is the mail I sent around last time – do you want to to change
> anything there?
>
> https://mail.haskell.org/pipermail/ghc-steering-committee/2022-January/002711.html
>
> Should I maybe remove the paragraph asking for “conservative members”?
>
> Also maybe think of people you’d personally like to nudge to apply.
>
> 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/20221003/578731e4/attachment.html>

From mail at joachim-breitner.de  Thu Oct  6 12:28:50 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Oct 2022 14:28:50 +0200
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
Message-ID: <affb8fbd469ef26dcc88491fe0c0403658295776.camel@joachim-breitner.de>

Dear Haskell community,

the GHC Steering committee is seeking nominations for one or more new
members.

The committee scrutinizes, nitpicks, improves, weighs and eventually
accepts or rejects proposals that extend or change the language
supported by GHC and other (public-facing) aspects of GHC.
Our processes are described at
   https://github.com/ghc-proposals/ghc-proposals
which is also the GitHub repository where proposals are proposed. In
particular, please have a look at the bylaws at
   https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst


We are looking for a member who has the ability 
 * to understand such language extension proposals,
 * to find holes and missing corner cases in the specifications,
 * foresee the interaction with other language features and 
   specifications,
 * comment constructively and improve the proposals,
 * judge the cost/benefit ratio and
 * finally come to a justifiable conclusion.

We look for committee members who have some of these properties:
 * have substantial experience in writing Haskell applications or
   libraries, which they can use to inform judgements about the
   utility or otherwise of proposed features,
 * have made active contributions to the Haskell community, for
   some time,
 * have expertise in language design and implementation, in either
   Haskell or related languages, which they can share with us.

There is no shortage of people who are eager to get fancy new features
into the language, both in the committee and the wider community. But
each new feature imposes a cost, to implement, to maintain in
perpetuity in GHC's code base, to learn, and to deal with its
unexpected interaction with other features. We need to strike a
balance, one that encourages innovation (as GHC always has) while still
making Haskell attractive for real-world production use and for
teaching. We therefore seek a balance of background, expertise, and
views on the committee.

Membership of the committee gives you the chance to influence the
future direction of Haskell, and to serve the Haskell community. The
committee’s work requires a small, but non-trivial amount of time,
especially when you are assigned a proposal for shepherding. We
estimate the workload to be around 2 hours per week, and our process
works best if members usually respond to technical emails within 1-2
weeks (within days is even better). Please keep that in mind if your
email inbox is already overflowing.

To nominate yourself, please send an email to me (as the committee
secretary) at mail at joachim-breitner.de until February 11th. I will
distribute the nominations among the committee, and we will keep the
nominations and our deliberations private.

On behalf of the committee,
Joachim Breitner

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


From mail at joachim-breitner.de  Thu Oct  6 12:31:54 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 06 Oct 2022 14:31:54 +0200
Subject: [ghc-steering-committee] Request for Nominations to the GHC
	Steering Committee
In-Reply-To: <affb8fbd469ef26dcc88491fe0c0403658295776.camel@joachim-breitner.de>
References: <affb8fbd469ef26dcc88491fe0c0403658295776.camel@joachim-breitner.de>
Message-ID: <a9f959935eedbca150a97c7c6cd5c11d07035eed.camel@joachim-breitner.de>

Sorry for that, but

Am Donnerstag, dem 06.10.2022 um 14:28 +0200 schrieb Joachim Breitner:
> To nominate yourself, please send an email to me (as the committee
> secretary) at mail at joachim-breitner.de until February 11th.
> 

should be October 16th.

Cheers,
Joachim


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


From mail at joachim-breitner.de  Sat Oct  8 10:06:20 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 08 Oct 2022 12:06:20 +0200
Subject: [ghc-steering-committee] Please review #526: Applicative
 Comprehensions, Shepherd: Simon M
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <a58600d85fd2bc17516debd072f8bb9086bcb7d9.camel@joachim-breitner.de>

Dear Committee,
Applicative comprehensions
have been proposed by M Farkas-Dyck

https://github.com/ghc-proposals/ghc-proposals/pull/516
https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst

I suggest Simon Marlow 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/


From arnaud.spiwack at tweag.io  Mon Oct 10 14:47:29 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Mon, 10 Oct 2022 16:47:29 +0200
Subject: [ghc-steering-committee] Please review #526: Applicative
 Comprehensions, Shepherd: Simon M
In-Reply-To: <a58600d85fd2bc17516debd072f8bb9086bcb7d9.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <a58600d85fd2bc17516debd072f8bb9086bcb7d9.camel@joachim-breitner.de>
Message-ID: <CAH6fHQn2y774w=JM5v6uO6C=3jT1k+=7zwB1yMa0M6egJb4ALA@mail.gmail.com>

The link to the pull request is incorrect in Joachim's email (though the
link to the text of the proposal is perfectly fine). The appropriate link
is https://github.com/ghc-proposals/ghc-proposals/pull/526

On Sat, Oct 8, 2022 at 12:06 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
> Applicative comprehensions
> have been proposed by M Farkas-Dyck
>
> https://github.com/ghc-proposals/ghc-proposals/pull/516
>
> https://github.com/strake/ghc-proposals/blob/acomp/proposals/0000-applicative-comprehensions.rst
>
> I suggest Simon Marlow 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221010/b661a85c/attachment.html>

From marlowsd at gmail.com  Tue Oct 18 13:32:24 2022
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 18 Oct 2022 14:32:24 +0100
Subject: [ghc-steering-committee] Proposal #522: Or patterns.
 Recommendation: accept
In-Reply-To: <010f0182ff0ede6c-9a73eb18-6238-42a2-b54a-f27d44de0e0d-000000@us-east-2.amazonses.com>
References: <010f0182b7fd3756-e5122221-8aa8-42ee-a12e-1841ac772f83-000000@us-east-2.amazonses.com>
 <CAJKmMz9W0q8350K4b_8gyhwB20ktucgHh_DdBnKzdDQ=vdcsMg@mail.gmail.com>
 <A24C9665-FBDA-4034-B7BF-6C563A1BB67E@chrisdornan.com>
 <010f0182ff0ede6c-9a73eb18-6238-42a2-b54a-f27d44de0e0d-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgP+p07GCjPaD7qmfeR6w4x46FOPRfRxSyGsAXuSN-_=zLg@mail.gmail.com>

The syntax is quite unsatisfying, reusing a symbol that has a different
meaning in expressions. Such a shame that | was used for guards. Oh well.
It's a useful feature though, I'm weakly in favour.

Simon

On Fri, 2 Sept 2022 at 17:36, Richard Eisenberg <lists at richarde.dev> wrote:

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

From lists at richarde.dev  Wed Oct 19 12:49:56 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 19 Oct 2022 12:49:56 +0000
Subject: [ghc-steering-committee] Please review #517: Require
 implementors before proposal submission, Shepherd: Simon PJ
In-Reply-To: <CAH6fHQnq1VCB6dcLkk=AXot+E4Hn87s0eQbBTTFi3kxN68w62g@mail.gmail.com>
References: <fea80f590b33487cc4998cc256cb1527aff0d4c1.camel@joachim-breitner.de>
 <CAJKmMz_B4YKK4HXd0Ur_LY9BGpdvcfxxVYbxiriQHZQbSvyExA@mail.gmail.com>
 <CAK9DwL_+=OYwL8sPx9LSa97TZ3qXo8hZk=nwrM7aCTOE+z5B3g@mail.gmail.com>
 <e06e6f94493a8728c35fc40e388eda7f0a35f406.camel@joachim-breitner.de>
 <CAH6fHQkagNsgEWgT+Fxoetj9W-GS8b46dXhVjxMZMR_Nad6MrQ@mail.gmail.com>
 <57641e5d2c3e4f5f061579665713faa1120341f1.camel@joachim-breitner.de>
 <0729707b8b57649f6815646cd59adf95a8e7b385.camel@joachim-breitner.de>
 <CAJKmMz-Q4K8kSyNuFnT08P+WaZcJ10Y70iWQioz7saYuoH7o0g@mail.gmail.com>
 <CAH6fHQnq1VCB6dcLkk=AXot+E4Hn87s0eQbBTTFi3kxN68w62g@mail.gmail.com>
Message-ID: <010f0183f04b17d6-fd1eeaa5-c04b-4ab5-afae-86ef51df82b8-000000@us-east-2.amazonses.com>

This all unfolded while I was laid flat by covid, but I would vote in favor of this proposal. I've seen sufficient evidence of folks unhappy with accepted-but-not-implemented proposals (most recently Matt Parsons about the modifiers proposal) that I think this would be an improvement.

That said, I think we should have broader support before accepting a proposal such as this.

Richard

> On Oct 3, 2022, at 4:28 AM, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> 
> If we do come back to it, it's going to be stronger evidence that something in that space is needed.
> 
> On Mon, Oct 3, 2022 at 10:26 AM Simon Peyton Jones <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
> As you say, it's not that big a deal.  I'm content to reject for now.  I'm sure we'll keep coming back to it!
> 
> Simon
> 
> On Sun, 2 Oct 2022 at 13:03, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Dienstag, dem 20.09.2022 um 15:43 +0200 schrieb Joachim Breitner:
> > So given that we don’t have a consensus, I suggest to not spend more
> > time on it, let’s reject it (and remember where it is to be revived, if
> > and when the problem becomes more clearer visible).
> 
> no complaints about this either? I’ll mark it as rejected in a few days
> unless someone shouts.
> 
> Cheers,
> Joachim
> 
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20221019/0baeee4d/attachment.html>

From mail at joachim-breitner.de  Mon Oct 24 06:51:56 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 24 Oct 2022 08:51:56 +0200
Subject: [ghc-steering-committee] Welcome Adam, welcome back Arnaud
Message-ID: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>

Dear all,

Adam Gundry has nominated himself to join the committee, and was voted
in, so welcome!

Adam, if you haven’t done so already, please subscribe to
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
and review the processes at
https://github.com/ghc-proposals/ghc-proposals/
https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst
https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst

You should have gotten a github invite to the repo.

Your opinion is valued on all proposals currently under review, even
those that were submitted before. Which, conveniently, is only one at
the moment and relates to records:
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
(but we do look forward to your opinion about proposals about other
corners of the language, of course :-))


Arnaud has also nominated himself and was voted back in for another
term. Thanks for staying with us!

Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Mon Oct 24 08:48:11 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 24 Oct 2022 09:48:11 +0100
Subject: [ghc-steering-committee] Welcome Adam, welcome back Arnaud
In-Reply-To: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>
References: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9665LK+GQh1R_jnqxFy3xyPZYWppznNQQ=59sB5g+auA@mail.gmail.com>

Welcome Adam!  And welcome back Arnaud.  Thank you!

Simon

On Mon, 24 Oct 2022 at 07:52, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear all,
>
> Adam Gundry has nominated himself to join the committee, and was voted
> in, so welcome!
>
> Adam, if you haven’t done so already, please subscribe to
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> and review the processes at
> https://github.com/ghc-proposals/ghc-proposals/
> https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst
> https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst
>
> You should have gotten a github invite to the repo.
>
> Your opinion is valued on all proposals currently under review, even
> those that were submitted before. Which, conveniently, is only one at
> the moment and relates to records:
>
> https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
> (but we do look forward to your opinion about proposals about other
> corners of the language, of course :-))
>
>
> Arnaud has also nominated himself and was voted back in for another
> term. Thanks for staying with us!
>
> 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/20221024/465a69bd/attachment.html>

From adam at well-typed.com  Mon Oct 24 19:10:17 2022
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 24 Oct 2022 20:10:17 +0100
Subject: [ghc-steering-committee] Welcome Adam, welcome back Arnaud
In-Reply-To: <CAJKmMz9665LK+GQh1R_jnqxFy3xyPZYWppznNQQ=59sB5g+auA@mail.gmail.com>
References: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>
 <CAJKmMz9665LK+GQh1R_jnqxFy3xyPZYWppznNQQ=59sB5g+auA@mail.gmail.com>
Message-ID: <0511ebda-b488-a340-a693-cad4b414e2a0@well-typed.com>

Thank you for the welcome! The one proposal awaiting committee review is 
one for which I'm a co-author, so I'll keep my authorial hat on for that 
one. :-)

Cheers,

Adam


On 24/10/2022 09:48, Simon Peyton Jones wrote:
> Welcome Adam!  And welcome back Arnaud.  Thank you!
> 
> Simon
> 
> On Mon, 24 Oct 2022 at 07:52, Joachim Breitner <mail at joachim-breitner.de 
> <mailto:mail at joachim-breitner.de>> wrote:
> 
>     Dear all,
> 
>     Adam Gundry has nominated himself to join the committee, and was voted
>     in, so welcome!
> 
>     Adam, if you haven’t done so already, please subscribe to
>     https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>     <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>     and review the processes at
>     https://github.com/ghc-proposals/ghc-proposals/
>     <https://github.com/ghc-proposals/ghc-proposals/>
>     https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst
>     <https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst>
>     https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst
>     <https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst>
> 
>     You should have gotten a github invite to the repo.
> 
>     Your opinion is valued on all proposals currently under review, even
>     those that were submitted before. Which, conveniently, is only one at
>     the moment and relates to records:
>     https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
>     <https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22>
>     (but we do look forward to your opinion about proposals about other
>     corners of the language, of course :-))
> 
> 
>     Arnaud has also nominated himself and was voted back in for another
>     term. Thanks for staying with us!
> 
>     Cheers,
>     Joachim
> 
>     -- 
>     Joachim Breitner
>     mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>     http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>


-- 
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 mail at joachim-breitner.de  Mon Oct 24 19:20:13 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 24 Oct 2022 21:20:13 +0200
Subject: [ghc-steering-committee] Welcome Adam, welcome back Arnaud
In-Reply-To: <0511ebda-b488-a340-a693-cad4b414e2a0@well-typed.com>
References: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>
 <CAJKmMz9665LK+GQh1R_jnqxFy3xyPZYWppznNQQ=59sB5g+auA@mail.gmail.com>
 <0511ebda-b488-a340-a693-cad4b414e2a0@well-typed.com>
Message-ID: <ce4dcb5c9e66322886384f738d7bf0146f344a8b.camel@joachim-breitner.de>

Hi,

Am Montag, dem 24.10.2022 um 20:10 +0100 schrieb Adam Gundry:
> Thank you for the welcome! The one proposal awaiting committee review is 
> one for which I'm a co-author, so I'll keep my authorial hat on for that 
> one. :-)

oh, of course, I only peeked at the first author. 

I’m sure we’ll get some proposals to review your way in due time :-)

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


From mail at joachim-breitner.de  Mon Oct 24 19:48:50 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 24 Oct 2022 21:48:50 +0200
Subject: [ghc-steering-committee] GHC2023
Message-ID: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>

Hi Committee,

when we defined the process for GHC20xx, as written in 
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
we wrote

   Likely, the first iteration of this process will be vastly different
   from the following ones: The first one is expected to add a large
   number of uncontroversial extensions; so the next iteration will
   likely only make a smaller, but more controversial change.

   Therefore, this proposal does not commit to a fixed cadence.
   Instead, 6 months after the first release of a version of GHC that
   supports a GHC20xx set, we evaluate the outcome, the process, and
   the perceived need of a next release. At that time we will refine
   the processes, if needed, and set a cadence.
 
The first version of GHC that supported GHC2021 was 9.2, released in
October 2022.

Last fall we said that not enough time has passed to do such an
evaluation, and we skipped defining GHC2022.

Another year has passed, and if we are serious with the idea that
GHC20xx is a continuous thing, we should probably start defining
GHC2023 – even if it is just a small delta. This e-mail tries to
kickstart that process.


Last time we did a relative elaborate thing where we voted on
essentially _every_ extension. I think that made sense for the first
iteration, where we had to winddow down the likely extensions. But now
we have a base line (GHC2021), and are asked to find a suitable delta,
and I’d go for a nomination-based approach: Committee members can
propose adding (or removing, in theory) specific extensions, and then
we vote only on those. Does that sound reasonable?

Does anyone have any insight from the real world? Has GHC2021 helped
our users? And if not, why not?

What kind of hard data would you like to see, if any?

(I’m a bit wary of spending too much time writing scripts to scrape
hackage, for example to see which extensions people tend to enable _in
addition_ to GHC2021, only to see that libraries on hackage are
understandably slow to use default-language: GHC2021, as that’s not
great for backward compat for now. But I am also not sure where to look
for good data…)

Cheers,
Joachim

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