From mail at joachim-breitner.de  Mon Jan  2 17:10:14 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 02 Jan 2023 18:10:14 +0100
Subject: [ghc-steering-committee] #511 Deep Subsumption,
 recommendation: accept
In-Reply-To: <CANsrgP+Ahvea92Wed66hgxgTKaPBv7K3OFeH=ntuTa3_0v9Y2g@mail.gmail.com>
References: <CAH6fHQm9hRn47dPu78non_rYA8c63zkcDPo6PevYwwRp0HHsRQ@mail.gmail.com>
 <CANsrgP+A2drK5zaRhZmLr=W6L5X28Oz70gJ+JLnDOdEY4oaU-g@mail.gmail.com>
 <cd8aa4dff81e6600e0b1a3c36ec777cf386a8fb3.camel@joachim-breitner.de>
 <CANsrgP+Ahvea92Wed66hgxgTKaPBv7K3OFeH=ntuTa3_0v9Y2g@mail.gmail.com>
Message-ID: <fad58c904e856865e67db253add559df90f54537.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 21.06.2022 um 11:45 +0100 schrieb Simon Marlow:
> > Slight digression, but does Cabal even allow specifying bounds on the
> > compiler implementation? If you put this into the build-depends it
> > might have that effect, but it will also depend on ghc-the-library, not
> > what people usually do.
> 
> Yes, you can do this (stolen from one of my .cabal files):
> 
>     if impl(ghc >= 8.8)
>       buildable: True
>     else
>       buildable: False

just in case someone reads our conversation here, TIL that the using
buildable is not quite correct, and should probably be

    if impl(ghc < 8.8)
      build-depends: unbuildable <0

according to Oleg in 
https://github.com/haskell/mtl/issues/138#issuecomment-1369068398

Cheers,
Joachim 


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


From marlowsd at gmail.com  Tue Jan  3 09:32:56 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 3 Jan 2023 09:32:56 +0000
Subject: [ghc-steering-committee] Why not?, rather than, why?
In-Reply-To: <010f0185235e2a41-63ee350a-34b0-408f-8871-f3ecfc18eccd-000000@us-east-2.amazonses.com>
References: <c9ca5ad1abf900e519881c28d85b27117bda2c33.camel@joachim-breitner.de>
 <CAGwnsnnz=pnEYgGRp6_8OtJE3tNLhn=g=9fzNP+6G6PMkX5ukQ@mail.gmail.com>
 <CANsrgPJg2NQsXr1nOiNs+UD6V54+9Am7P9q_x0SeqxSiY+cJMg@mail.gmail.com>
 <C65BC615-B9A5-481E-A4E0-96966C80DEDC@chrisdornan.com>
 <a924a68a2953736cd84f266a52d8fb4d3ef031c5.camel@joachim-breitner.de>
 <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com>
 <CANsrgPLEge8bWnOepfSdCd89fO1cmqzQi+kokTq9DLp_4SvSUQ@mail.gmail.com>
 <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com>
 <CAGwnsnnDsOgixQv7LbvL4LPZAxPuECfc=dqBhfpO-p0ZLYxjOQ@mail.gmail.com>
 <CAJKmMz8EtN1=AgVdX1xUR3kio44hZH5yyCHqGfNgGZYHNSjAxw@mail.gmail.com>
 <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com>
 <cf6929e22e51ea445d74346f5b20a7abfc55766c.camel@joachim-breitner.de>
 <CAGwnsnk14gnf+8nVbvWemG=zqZnJv+SOSwbxGk5WyoPJB5346Q@mail.gmail.com>
 <CANsrgP+oJT7bs7F4Bj_mzsGQfh6nwWVxWzj2K69j1DHzjxH8Cg@mail.gmail.com>
 <010f0185235e2a41-63ee350a-34b0-408f-8871-f3ecfc18eccd-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgPJF=ekHuJ4WdL69ZZdjV5N2w9gZiAQK7feBEjePdCeypw@mail.gmail.com>

On Sun, 18 Dec 2022 at 03:54, Richard Eisenberg <lists at richarde.dev> wrote:

>
>
> On Dec 14, 2022, at 6:05 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> It's clear that CPP needs to remain as a flag because it does bad things
> to the syntax like breaking multiline strings and doing strange things to
> `##`. But it's less clear to me that TemplateHaskell is in this category.
> Isn't it just an extension that enables new syntax? Yes there are
> *practical* reasons why we might not want it on by default, because it
> makes compilation slower and whatnot, but isn't that all it is?
>
>
> I somehow missed this, and more surprisingly just now found it.
>
> TemplateHaskell isn't just for new syntax primarily because it has
> important interactions around cross-compilation. If/when GHC has a
> comprehensive story around cross-compilation, TH will change the way the
> pipeline works. It was this concern that suggested it should be lumped with
> CPP. (TemplateHaskellQuotes are a different story -- that's just syntax.)
>

I think of cross-compilation as just a tooling issue that affects how you
actually *implement* TH, but not something that changes what it means. Or
perhaps I'm wrong? Is there a way in which enabling TH will change the
meaning of a program that doesn't use any TH?

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

From lists at richarde.dev  Tue Jan  3 13:17:02 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 3 Jan 2023 13:17:02 +0000
Subject: [ghc-steering-committee] Why not?, rather than, why?
In-Reply-To: <CANsrgPJF=ekHuJ4WdL69ZZdjV5N2w9gZiAQK7feBEjePdCeypw@mail.gmail.com>
References: <c9ca5ad1abf900e519881c28d85b27117bda2c33.camel@joachim-breitner.de>
 <CAGwnsnnz=pnEYgGRp6_8OtJE3tNLhn=g=9fzNP+6G6PMkX5ukQ@mail.gmail.com>
 <CANsrgPJg2NQsXr1nOiNs+UD6V54+9Am7P9q_x0SeqxSiY+cJMg@mail.gmail.com>
 <C65BC615-B9A5-481E-A4E0-96966C80DEDC@chrisdornan.com>
 <a924a68a2953736cd84f266a52d8fb4d3ef031c5.camel@joachim-breitner.de>
 <10594AD6-665D-4674-8E96-78AB6C61973A@chrisdornan.com>
 <CANsrgPLEge8bWnOepfSdCd89fO1cmqzQi+kokTq9DLp_4SvSUQ@mail.gmail.com>
 <6D754A68-7BC5-48AF-A6A8-B307D9FD02EB@chrisdornan.com>
 <CAGwnsnnDsOgixQv7LbvL4LPZAxPuECfc=dqBhfpO-p0ZLYxjOQ@mail.gmail.com>
 <CAJKmMz8EtN1=AgVdX1xUR3kio44hZH5yyCHqGfNgGZYHNSjAxw@mail.gmail.com>
 <010f0184f74380f9-b587b4d5-59af-4f09-8efe-4ad1745243ce-000000@us-east-2.amazonses.com>
 <cf6929e22e51ea445d74346f5b20a7abfc55766c.camel@joachim-breitner.de>
 <CAGwnsnk14gnf+8nVbvWemG=zqZnJv+SOSwbxGk5WyoPJB5346Q@mail.gmail.com>
 <CANsrgP+oJT7bs7F4Bj_mzsGQfh6nwWVxWzj2K69j1DHzjxH8Cg@mail.gmail.com>
 <010f0185235e2a41-63ee350a-34b0-408f-8871-f3ecfc18eccd-000000@us-east-2.amazonses.com>
 <CANsrgPJF=ekHuJ4WdL69ZZdjV5N2w9gZiAQK7feBEjePdCeypw@mail.gmail.com>
Message-ID: <010f018577c73766-01d29098-6ed0-42e1-8eb1-7b587296e145-000000@us-east-2.amazonses.com>



> On Jan 3, 2023, at 4:32 AM, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I think of cross-compilation as just a tooling issue that affects how you actually *implement* TH, but not something that changes what it means. Or perhaps I'm wrong? Is there a way in which enabling TH will change the meaning of a program that doesn't use any TH?
> 

It means you have to be able to compile code that targets the host, not just the target. I suppose this property is also required by GHCi, but it's otherwise unrequired (I think). TH also affects recompilation-avoidance computations. Maybe it makes sense to use the existence of an actual splice to control this all, though, so we could plausibly put TH in the "just allows new syntax" category.

Richard

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

From mail at joachim-breitner.de  Sun Jan  8 10:35:46 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 08 Jan 2023 11:35:46 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
Message-ID: <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 23.11.2022 um 17:51 +0100 schrieb Joachim Breitner:
> encouraged by Arnaud reports about Rust editions, and also in light of
> the ExplicitNamespaces “bug” in GHC2021, I’m now starting a proposal to
> define GHC2023. 
> 
> Please see
> https://github.com/ghc-proposals/ghc-proposals/pull/559
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>
> The proposal text succinctly tries to alleviate worries that this is
> “too soon”, and gives motivation for the nominated extensions.
> 
> At the moment it suggest to add ExplicitNamespaces and LambdaCase
> 
> I invite all committee members to 
>  * nominate more extensions to add
>  * bring arguments in favor of an extension
>  * bring arguments against an extension
> 
> You can either add them directly (via suggested edits) to the proposal
> text, or write them here and I’ll paraphrase them into that document,
> to try to summarize the discussion well.
> 
> Once that phase seems concluded, I’ll invite you to vote. Not sure yet
> how precisely, but we’ll vote in a way that one can also express that
> no GHC2023 should happen.

I have not seen much engagement from the committee on this PR, and I
sense a certain reluctance to have another GHC20xx this year. But I
don’t want us to deviate from the original accepted plan just because
of implicit assumptions, nor get bogged down by the more fundamental
(and important!) discussion about the role of extensions in general.

So let’s bring this to a vote – if the camp that prefers even rarer
releases is in the majority, the vote will show that. 

I’m still fairly convinced that we are doing the community a service if
we take the idea of GHC20xx editions as a continuous and predictable
stream of improvements serious. Even if the delta is kinda small.
Actually, I should say: _Especially_ if the delta is kinda small! This
takes the anxiety out of “anew GHC20xx has been released”, just like
the now bi-yearly GHC releases ideally don’t scare anyone anymore, as
it helps us get used to and gain practice with the process.

So let’s collect possibly more nominations and otherwise discuss with
the community on the PR for two more weeks (until roughly Sun, Jan 22).
If you’d like to get an extension on the ballot, or expand the
rationale for an extension, simply edit 
https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst

Then I will ask a for a vote. The ballot will roughly look like this:

  For each of the following extension, should it become part of
  GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.

  GotoStatement
  SemanticComments
  ImplementationByChatGTP

We’ll have GHC2023 if _at leas one_ extension has a majority of “strong
yes” vote, and it will contain those extensions that have a majority of
“yes” votes.

This allows you to distinguish between “worth having GHC2023 for” from
“not worth having GHC2023 for, but good enough to include if we have
GHC2023 anyways”. For example if you think there shouldn’t be a
GHC2023, you just never vote “strong yes”, but you can still have a say
what should be in it if it happens, by voting “weak yes” or “no”.


Cheers,
Joachim






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


From chris at chrisdornan.com  Sun Jan  8 19:33:19 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 8 Jan 2023 19:33:19 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
Message-ID: <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>

> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious.

Very well put -- count me in. I think the anxiety around us generating more things that the community has to think about is understandable, but other than that there isn't a great deal of substance to the objections, but I think the idea of a steady stream of refinement around what we think should be in 'modern base Haskell' is a strong and important one, and a steady effort of refinement is I am sure going to lead to a better and more rational result than periodic bun fights to determine what is going into the next decade of 'modern base Haskell'.

So I vote yes to continuing to think about what we want in ghc2023.

Thanks again Joachim for (again) keeping us on track.

Chris

> On 8 Jan 2023, at 10:35, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Mittwoch, dem 23.11.2022 um 17:51 +0100 schrieb Joachim Breitner:
>> encouraged by Arnaud reports about Rust editions, and also in light of
>> the ExplicitNamespaces “bug” in GHC2021, I’m now starting a proposal to
>> define GHC2023. 
>> 
>> Please see
>> https://github.com/ghc-proposals/ghc-proposals/pull/559
>> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>> 
>> The proposal text succinctly tries to alleviate worries that this is
>> “too soon”, and gives motivation for the nominated extensions.
>> 
>> At the moment it suggest to add ExplicitNamespaces and LambdaCase
>> 
>> I invite all committee members to 
>> * nominate more extensions to add
>> * bring arguments in favor of an extension
>> * bring arguments against an extension
>> 
>> You can either add them directly (via suggested edits) to the proposal
>> text, or write them here and I’ll paraphrase them into that document,
>> to try to summarize the discussion well.
>> 
>> Once that phase seems concluded, I’ll invite you to vote. Not sure yet
>> how precisely, but we’ll vote in a way that one can also express that
>> no GHC2023 should happen.
> 
> I have not seen much engagement from the committee on this PR, and I
> sense a certain reluctance to have another GHC20xx this year. But I
> don’t want us to deviate from the original accepted plan just because
> of implicit assumptions, nor get bogged down by the more fundamental
> (and important!) discussion about the role of extensions in general.
> 
> So let’s bring this to a vote – if the camp that prefers even rarer
> releases is in the majority, the vote will show that. 
> 
> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious. Even if the delta is kinda small.
> Actually, I should say: _Especially_ if the delta is kinda small! This
> takes the anxiety out of “anew GHC20xx has been released”, just like
> the now bi-yearly GHC releases ideally don’t scare anyone anymore, as
> it helps us get used to and gain practice with the process.
> 
> So let’s collect possibly more nominations and otherwise discuss with
> the community on the PR for two more weeks (until roughly Sun, Jan 22).
> If you’d like to get an extension on the ballot, or expand the
> rationale for an extension, simply edit 
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst <https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst>
> 
> Then I will ask a for a vote. The ballot will roughly look like this:
> 
>  For each of the following extension, should it become part of
>  GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
> 
>  GotoStatement
>  SemanticComments
>  ImplementationByChatGTP
> 
> We’ll have GHC2023 if _at leas one_ extension has a majority of “strong
> yes” vote, and it will contain those extensions that have a majority of
> “yes” votes.
> 
> This allows you to distinguish between “worth having GHC2023 for” from
> “not worth having GHC2023 for, but good enough to include if we have
> GHC2023 anyways”. For example if you think there shouldn’t be a
> GHC2023, you just never vote “strong yes”, but you can still have a say
> what should be in it if it happens, by voting “weak yes” or “no”.
> 
> 
> Cheers,
> Joachim
> 
> 
> 
> 
> 
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>  http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230108/b5be47ea/attachment-0001.html>

From mail at joachim-breitner.de  Tue Jan 10 09:06:16 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jan 2023 10:06:16 +0100
Subject: [ghc-steering-committee] Please review #555: Higher Order Patterns
 in Rewrite Rules, Shepherd Simon PJ
Message-ID: <2f746f85421c4ab77e926b60a8de92e442c29e69.camel@joachim-breitner.de>

Dear Committee,

Jaro Reinders proposes
Higher Order Patterns in Rewrite Rules
https://github.com/ghc-proposals/ghc-proposals/pull/555
https://github.com/noughtmare/ghc-proposals/blob/template-applications/proposals/0000-template-patterns.rst

I suggest Simon PJ to shepherd this proposal, because everyone else
already has at least one proposal on their plate (hint hint), and he
already conversed 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 simon.peytonjones at gmail.com  Tue Jan 10 09:09:47 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 10 Jan 2023 09:09:47 +0000
Subject: [ghc-steering-committee] Please review #555: Higher Order
 Patterns in Rewrite Rules, Shepherd Simon PJ
In-Reply-To: <2f746f85421c4ab77e926b60a8de92e442c29e69.camel@joachim-breitner.de>
References: <2f746f85421c4ab77e926b60a8de92e442c29e69.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8ydu_QOPw5PV-7yXn2aEeao-q6R9DA_BEzrTitp1Azyg@mail.gmail.com>

Well I'm a co-author of the proposal.  Quite a bit of the text is mine.
Are you sure you want me as the shepherd?

If so I'll recommend acceptance.

Simon

On Tue, 10 Jan 2023 at 09:06, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Jaro Reinders proposes
> Higher Order Patterns in Rewrite Rules
> https://github.com/ghc-proposals/ghc-proposals/pull/555
>
> https://github.com/noughtmare/ghc-proposals/blob/template-applications/proposals/0000-template-patterns.rst
>
> I suggest Simon PJ to shepherd this proposal, because everyone else
> already has at least one proposal on their plate (hint hint), and he
> already conversed 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/
>
> _______________________________________________
> 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/20230110/c3f8495d/attachment.html>

From mail at joachim-breitner.de  Tue Jan 10 09:13:06 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jan 2023 10:13:06 +0100
Subject: [ghc-steering-committee] Please review #555: Higher Order
 Patterns in Rewrite Rules, Shepherd: Joachim
In-Reply-To: <CAJKmMz8ydu_QOPw5PV-7yXn2aEeao-q6R9DA_BEzrTitp1Azyg@mail.gmail.com>
References: <2f746f85421c4ab77e926b60a8de92e442c29e69.camel@joachim-breitner.de>
 <CAJKmMz8ydu_QOPw5PV-7yXn2aEeao-q6R9DA_BEzrTitp1Azyg@mail.gmail.com>
Message-ID: <e9615c8424308413f0e3cdd5015625c69e7a3a4e.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 10.01.2023 um 09:09 +0000 schrieb Simon Peyton Jones:
> Well I'm a co-author of the proposal.  Quite a bit of the text is
> mine.  Are you sure you want me as the shepherd?

oh, sorry, I wasn’t paying close enough attention. (And you are not
listed as an author in the metadata on
https://github.com/noughtmare/ghc-proposals/blob/template-applications/proposals/0000-template-patterns.rst
maybe you want to add yourself).

I’ll shepherd this myself then :-)

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


From simon.peytonjones at gmail.com  Tue Jan 10 10:06:29 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 10 Jan 2023 10:06:29 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
Message-ID: <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>

>
> So let’s bring this to a vote – if the camp that prefers even rarer
> releases is in the majority, the vote will show that.
>

Well, it will if that's what we vote on, but you are suggesting

  For each of the following extension, should it become part of
>   GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
>

I rather think we should *first *decide on GHC20xx cadence.  Our advertised
cadence is advertised as annual, but my instinct is that's too frequent.
I'd just every 3 yrs, which appears to match Rust.

Can we vote on that first?

Simon


On Sun, 8 Jan 2023 at 19:33, Chris Dornan <chris at chrisdornan.com> wrote:

> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious.
>
>
> Very well put -- count me in. I think the anxiety around us generating
> more things that the community has to think about is understandable, but
> other than that there isn't a great deal of substance to the objections,
> but I think the idea of a steady stream of refinement around what we think
> should be in 'modern base Haskell' is a strong and important one, and a
> steady effort of refinement is I am sure going to lead to a better and more
> rational result than periodic bun fights to determine what is going into
> the next decade of 'modern base Haskell'.
>
> So I vote yes to continuing to think about what we want in ghc2023.
>
> Thanks again Joachim for (again) keeping us on track.
>
> Chris
>
> On 8 Jan 2023, at 10:35, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
> Hi,
>
> Am Mittwoch, dem 23.11.2022 um 17:51 +0100 schrieb Joachim Breitner:
>
> encouraged by Arnaud reports about Rust editions, and also in light of
> the ExplicitNamespaces “bug” in GHC2021, I’m now starting a proposal to
> define GHC2023.
>
> Please see
> https://github.com/ghc-proposals/ghc-proposals/pull/559
>
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>
> The proposal text succinctly tries to alleviate worries that this is
> “too soon”, and gives motivation for the nominated extensions.
>
> At the moment it suggest to add ExplicitNamespaces and LambdaCase
>
> I invite all committee members to
> * nominate more extensions to add
> * bring arguments in favor of an extension
> * bring arguments against an extension
>
> You can either add them directly (via suggested edits) to the proposal
> text, or write them here and I’ll paraphrase them into that document,
> to try to summarize the discussion well.
>
> Once that phase seems concluded, I’ll invite you to vote. Not sure yet
> how precisely, but we’ll vote in a way that one can also express that
> no GHC2023 should happen.
>
>
> I have not seen much engagement from the committee on this PR, and I
> sense a certain reluctance to have another GHC20xx this year. But I
> don’t want us to deviate from the original accepted plan just because
> of implicit assumptions, nor get bogged down by the more fundamental
> (and important!) discussion about the role of extensions in general.
>
> So let’s bring this to a vote – if the camp that prefers even rarer
> releases is in the majority, the vote will show that.
>
> I’m still fairly convinced that we are doing the community a service if
> we take the idea of GHC20xx editions as a continuous and predictable
> stream of improvements serious. Even if the delta is kinda small.
> Actually, I should say: _Especially_ if the delta is kinda small! This
> takes the anxiety out of “anew GHC20xx has been released”, just like
> the now bi-yearly GHC releases ideally don’t scare anyone anymore, as
> it helps us get used to and gain practice with the process.
>
> So let’s collect possibly more nominations and otherwise discuss with
> the community on the PR for two more weeks (until roughly Sun, Jan 22).
> If you’d like to get an extension on the ballot, or expand the
> rationale for an extension, simply edit
>
> https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2023/proposals/0000-ghc2023.rst
>
> Then I will ask a for a vote. The ballot will roughly look like this:
>
>  For each of the following extension, should it become part of
>  GHC2023? Please annotate with “strong yes”, “weak yes” or “no”.
>
>  GotoStatement
>  SemanticComments
>  ImplementationByChatGTP
>
> We’ll have GHC2023 if _at leas one_ extension has a majority of “strong
> yes” vote, and it will contain those extensions that have a majority of
> “yes” votes.
>
> This allows you to distinguish between “worth having GHC2023 for” from
> “not worth having GHC2023 for, but good enough to include if we have
> GHC2023 anyways”. For example if you think there shouldn’t be a
> GHC2023, you just never vote “strong yes”, but you can still have a say
> what should be in it if it happens, by voting “weak yes” or “no”.
>
>
> 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/20230110/9093fefe/attachment-0001.html>

From mail at joachim-breitner.de  Tue Jan 10 10:13:43 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jan 2023 11:13:43 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
Message-ID: <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
> > So let’s bring this to a vote – if the camp that prefers even rarer
> > releases is in the majority, the vote will show that. 
> > 
> 
> Well, it will if that's what we vote on, but you are suggesting 
> …
> Can we vote on that first?

That’s part of the vote – just don’t say “strong yes” for any option if
you think it’s too early. “Strong yes” means “I think there should be a
GHC2023 because of extension X”.
If a majority votes at most “weak yes” to every extension, then there
will be no GHC2023.

I find a separate vote “should we have GHC2023” is not that meaningful
if it would be equal to GHC2021 anyways (assuming no extenion gets then
voted in) so it seems prudent to ask “Is there even any extension that
warrants having GHC2023.”

>  I'd just every 3 yrs, which appears to match Rust.

I think the comparision is misleading. Rust bundles _breaking_ changes
every 3 years. Nonbreaking, purely additive, syntax guarded, features
come out continuously. If we follow their model, we can have GHC20xx
yearly (or more often!), as long as we hold back _breaking_ changes to
a three-yearly cadence. (Which seems quite a reasonably policy.)

Cheers,
Joachim



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


From simon.peytonjones at gmail.com  Tue Jan 10 10:31:33 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 10 Jan 2023 10:31:33 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>

>
> That’s part of the vote – just don’t say “strong yes” for any option if
> you think it’s too early. “Strong yes” means “I think there should be a
> GHC2023 because of extension X”.
>

It seems a very funny way to do it.  I'd prefer to ask "what cadence do we
want" and then move on to discuss features individually.  At the moment I
might think "yes, extension X belongs in the next GHC20xx", so do I vote
yes or no for X?

What do other members of the committee think about cadence?  RSVP!  You are
a member!

Simon

On Tue, 10 Jan 2023 at 10:13, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, dem 10.01.2023 um 10:06 +0000 schrieb Simon Peyton Jones:
> > > So let’s bring this to a vote – if the camp that prefers even rarer
> > > releases is in the majority, the vote will show that.
> > >
> >
> > Well, it will if that's what we vote on, but you are suggesting
> > …
> > Can we vote on that first?
>
> That’s part of the vote – just don’t say “strong yes” for any option if
> you think it’s too early. “Strong yes” means “I think there should be a
> GHC2023 because of extension X”.
> If a majority votes at most “weak yes” to every extension, then there
> will be no GHC2023.
>
> I find a separate vote “should we have GHC2023” is not that meaningful
> if it would be equal to GHC2021 anyways (assuming no extenion gets then
> voted in) so it seems prudent to ask “Is there even any extension that
> warrants having GHC2023.”
>
> >  I'd just every 3 yrs, which appears to match Rust.
>
> I think the comparision is misleading. Rust bundles _breaking_ changes
> every 3 years. Nonbreaking, purely additive, syntax guarded, features
> come out continuously. If we follow their model, we can have GHC20xx
> yearly (or more often!), as long as we hold back _breaking_ changes to
> a three-yearly cadence. (Which seems quite a reasonably policy.)
>
> Cheers,
> Joachim
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230110/573eafdc/attachment.html>

From mail at joachim-breitner.de  Tue Jan 10 10:43:53 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jan 2023 11:43:53 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
Message-ID: <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
> 
> It seems a very funny way to do it.  I'd prefer to ask "what cadence
> do we want" and then move on to discuss features individually.  At
> the moment I might think "yes, extension X belongs in the next
> GHC20xx", so do I vote yes or no for X?

Ah, I see the confusion. The question is _not_ about “the next
GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
answer may well be “no extension is pressing enough to make a release
now”.

A year ago we concluded to

> don’t work on defining GHC2022, and the next update
> will be GHC2023 (or later).

and now we have to decide if it’s going to be GHC2023 or later.

Maybe what I want to say is that by deciding whether we have GHC2023 or
not, we are (implicitly) setting a precedence for what could become a
regular cadence, should we not change our minds in the following years.


> What do other members of the committee think about cadence?  RSVP!  
> You are a member!

I’m also curious :-)

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


From mail at joachim-breitner.de  Tue Jan 10 11:17:20 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 10 Jan 2023 12:17:20 +0100
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
	Rules, rec accept
Message-ID: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>

Dear Committee,

Jaro Reinders and Simon PJ propose to allow  Higher Order Patterns in Rewrite
Rules.

The idea, by way of an example,

   {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}
   
will now not only match "foo (\y. negate y + negate y)" (with f set to negate)
but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).

Here "f y" is a higher-order pattern, which are restricted to a
_pattern_ variable followed by a list of _local_ variable, indicating
which variable the matched expression may depend on (previously, only
closed expressions could be matched).

An implementation is sitting ready at
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343

The design was carefully crafted to be backward-compatible and not
introduce spurious etwa-expansion where there was non before.

It is not guarded by a LANGUAGE pragma (but RULES themselves are not).
Library authors who care about backward compat will have to deal with
CPP pragmas.


I’m a big fan of rewrite rules, and the proposal is straight forward
and provides a feature that I'd maybe optimistically already assumed to
be there already. Therefore, I’m recommending acceptance.

If you disagree please speak up within two weeks, or speed up the
process by indicating agreement earlier.

Cheers,
Joachim

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


From arnaud.spiwack at tweag.io  Wed Jan 11 09:29:20 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 11 Jan 2023 10:29:20 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
Message-ID: <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>

Empirically, I don't feel quite ready to make a call for GHC2023. So I
think that I'd favour a 3-year cadence.

On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
> >
> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
> > do we want" and then move on to discuss features individually.  At
> > the moment I might think "yes, extension X belongs in the next
> > GHC20xx", so do I vote yes or no for X?
>
> Ah, I see the confusion. The question is _not_ about “the next
> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
> answer may well be “no extension is pressing enough to make a release
> now”.
>
> A year ago we concluded to
>
> > don’t work on defining GHC2022, and the next update
> > will be GHC2023 (or later).
>
> and now we have to decide if it’s going to be GHC2023 or later.
>
> Maybe what I want to say is that by deciding whether we have GHC2023 or
> not, we are (implicitly) setting a precedence for what could become a
> regular cadence, should we not change our minds in the following years.
>
>
> > What do other members of the committee think about cadence?  RSVP!
> > You are a member!
>
> I’m also curious :-)
>
> 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/20230111/95b714bf/attachment.html>

From lists at richarde.dev  Wed Jan 11 13:27:58 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Wed, 11 Jan 2023 13:27:58 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
Message-ID: <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>

I'd personally rather spend our collective energies on landing the thoughts in our "Policy on Language Extensions" document. That is, work out any remaining points of disagreement and then move the document into the repo. In particular, if we end up in a place where we're content to add new syntax-guarded features without a new extension flag, that will, in turn, inform the GHC2023 idea.

I don't have the bandwidth to both work on GHC's type-checker (as I'm doing weekly, as Simon and I coordinate) and push such a thing through. Though if no one else wants to land that document, I think it's worth my slowing down type-checker work for a few weeks to do so. So any other volunteers here? Sorry to redirect us from the immediate task at hand -- GHC2023 -- but one of my principles is that it's best to work out principles (i.e. our policy on extensions) before specifics.

Richard

> On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> Empirically, I don't feel quite ready to make a call for GHC2023. So I think that I'd favour a 3-year cadence.
> 
> On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Hi,
> 
> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
> > 
> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
> > do we want" and then move on to discuss features individually.  At
> > the moment I might think "yes, extension X belongs in the next
> > GHC20xx", so do I vote yes or no for X?
> 
> Ah, I see the confusion. The question is _not_ about “the next
> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
> answer may well be “no extension is pressing enough to make a release
> now”.
> 
> A year ago we concluded to
> 
> > don’t work on defining GHC2022, and the next update
> > will be GHC2023 (or later).
> 
> and now we have to decide if it’s going to be GHC2023 or later.
> 
> Maybe what I want to say is that by deciding whether we have GHC2023 or
> not, we are (implicitly) setting a precedence for what could become a
> regular cadence, should we not change our minds in the following years.
> 
> 
> > What do other members of the committee think about cadence?  RSVP!  
> > You are a member!
> 
> I’m also curious :-)
> 
> 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
> 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/20230111/34b6d8ce/attachment.html>

From marlowsd at gmail.com  Wed Jan 11 14:55:00 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Wed, 11 Jan 2023 14:55:00 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
 <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>

I was just perusing the doc and after a flurry of activity it seems to be
stalled in various places. I doubt we'll make more progress without someone
actively driving it to a conclusion - several of the threads just end up in
minor differences of opinion and nobody feels enough ownership to resolve
them with edits directly. Meanwhile, the comments on the doc are getting a
bit unwieldy to work with.

Still, I think it has been super useful so far - in particular the idea of
using the warning system instead of turning off extensions is a really nice
simplification.

I personally have sporadic time to work on this but probably not enough to
satisfactorily drive it. Richard, I'd be very happy if you wanted to take
this on; alternatively we can continue via email as best we can.

I think we should next
1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2)
2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)

Cheers
Simon

On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists at richarde.dev> wrote:

> I'd personally rather spend our collective energies on landing the
> thoughts in our "Policy on Language Extensions" document. That is, work out
> any remaining points of disagreement and then move the document into the
> repo. In particular, if we end up in a place where we're content to add new
> syntax-guarded features without a new extension flag, that will, in turn,
> inform the GHC2023 idea.
>
> I don't have the bandwidth to both work on GHC's type-checker (as I'm
> doing weekly, as Simon and I coordinate) and push such a thing through.
> Though if no one else wants to land that document, I think it's worth my
> slowing down type-checker work for a few weeks to do so. So any other
> volunteers here? Sorry to redirect us from the immediate task at hand --
> GHC2023 -- but one of my principles is that it's best to work out
> principles (i.e. our policy on extensions) before specifics.
>
> Richard
>
> On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
> Empirically, I don't feel quite ready to make a call for GHC2023. So I
> think that I'd favour a 3-year cadence.
>
> On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
>> >
>> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
>> > do we want" and then move on to discuss features individually.  At
>> > the moment I might think "yes, extension X belongs in the next
>> > GHC20xx", so do I vote yes or no for X?
>>
>> Ah, I see the confusion. The question is _not_ about “the next
>> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
>> answer may well be “no extension is pressing enough to make a release
>> now”.
>>
>> A year ago we concluded to
>>
>> > don’t work on defining GHC2022, and the next update
>> > will be GHC2023 (or later).
>>
>> and now we have to decide if it’s going to be GHC2023 or later.
>>
>> Maybe what I want to say is that by deciding whether we have GHC2023 or
>> not, we are (implicitly) setting a precedence for what could become a
>> regular cadence, should we not change our minds in the following years.
>>
>>
>> > What do other members of the committee think about cadence?  RSVP!
>> > You are a member!
>>
>> I’m also curious :-)
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230111/de2179f2/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 12 09:23:45 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 12 Jan 2023 09:23:45 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
 <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
 <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>
Message-ID: <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>

Just to check: you are talking about this doc: Policy on language extensions
<https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing>

I agree that it would be sensible to sort this doc first.

Arnaud might be another possible driving force to getting it done?

Simon

On Wed, 11 Jan 2023 at 14:55, Simon Marlow <marlowsd at gmail.com> wrote:

> I was just perusing the doc and after a flurry of activity it seems to be
> stalled in various places. I doubt we'll make more progress without someone
> actively driving it to a conclusion - several of the threads just end up in
> minor differences of opinion and nobody feels enough ownership to resolve
> them with edits directly. Meanwhile, the comments on the doc are getting a
> bit unwieldy to work with.
>
> Still, I think it has been super useful so far - in particular the idea of
> using the warning system instead of turning off extensions is a really nice
> simplification.
>
> I personally have sporadic time to work on this but probably not enough to
> satisfactorily drive it. Richard, I'd be very happy if you wanted to take
> this on; alternatively we can continue via email as best we can.
>
> I think we should next
> 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2)
> 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)
>
> Cheers
> Simon
>
> On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> I'd personally rather spend our collective energies on landing the
>> thoughts in our "Policy on Language Extensions" document. That is, work out
>> any remaining points of disagreement and then move the document into the
>> repo. In particular, if we end up in a place where we're content to add new
>> syntax-guarded features without a new extension flag, that will, in turn,
>> inform the GHC2023 idea.
>>
>> I don't have the bandwidth to both work on GHC's type-checker (as I'm
>> doing weekly, as Simon and I coordinate) and push such a thing through.
>> Though if no one else wants to land that document, I think it's worth my
>> slowing down type-checker work for a few weeks to do so. So any other
>> volunteers here? Sorry to redirect us from the immediate task at hand --
>> GHC2023 -- but one of my principles is that it's best to work out
>> principles (i.e. our policy on extensions) before specifics.
>>
>> Richard
>>
>> On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> Empirically, I don't feel quite ready to make a call for GHC2023. So I
>> think that I'd favour a 3-year cadence.
>>
>> On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
>>> >
>>> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
>>> > do we want" and then move on to discuss features individually.  At
>>> > the moment I might think "yes, extension X belongs in the next
>>> > GHC20xx", so do I vote yes or no for X?
>>>
>>> Ah, I see the confusion. The question is _not_ about “the next
>>> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
>>> answer may well be “no extension is pressing enough to make a release
>>> now”.
>>>
>>> A year ago we concluded to
>>>
>>> > don’t work on defining GHC2022, and the next update
>>> > will be GHC2023 (or later).
>>>
>>> and now we have to decide if it’s going to be GHC2023 or later.
>>>
>>> Maybe what I want to say is that by deciding whether we have GHC2023 or
>>> not, we are (implicitly) setting a precedence for what could become a
>>> regular cadence, should we not change our minds in the following years.
>>>
>>>
>>> > What do other members of the committee think about cadence?  RSVP!
>>> > You are a member!
>>>
>>> I’m also curious :-)
>>>
>>> Cheers,
>>> Joachim
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230112/667eec2c/attachment-0001.html>

From marlowsd at gmail.com  Thu Jan 12 15:53:07 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Thu, 12 Jan 2023 15:53:07 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
 <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
 <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>
 <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>
Message-ID: <CANsrgPLu_5AuCiH07vi=-xZ4=rNyerj1WY7GZwrFns-DVRfr-A@mail.gmail.com>

On Thu, 12 Jan 2023 at 09:23, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Just to check: you are talking about this doc: Policy on language
> extensions
> <https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing>
>

Yes




>
> I agree that it would be sensible to sort this doc first.
>
> Arnaud might be another possible driving force to getting it done?
>
> Simon
>
> On Wed, 11 Jan 2023 at 14:55, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> I was just perusing the doc and after a flurry of activity it seems to be
>> stalled in various places. I doubt we'll make more progress without someone
>> actively driving it to a conclusion - several of the threads just end up in
>> minor differences of opinion and nobody feels enough ownership to resolve
>> them with edits directly. Meanwhile, the comments on the doc are getting a
>> bit unwieldy to work with.
>>
>> Still, I think it has been super useful so far - in particular the idea
>> of using the warning system instead of turning off extensions is a really
>> nice simplification.
>>
>> I personally have sporadic time to work on this but probably not enough
>> to satisfactorily drive it. Richard, I'd be very happy if you wanted to
>> take this on; alternatively we can continue via email as best we can.
>>
>> I think we should next
>> 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2)
>> 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)
>>
>> Cheers
>> Simon
>>
>> On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists at richarde.dev>
>> wrote:
>>
>>> I'd personally rather spend our collective energies on landing the
>>> thoughts in our "Policy on Language Extensions" document. That is, work out
>>> any remaining points of disagreement and then move the document into the
>>> repo. In particular, if we end up in a place where we're content to add new
>>> syntax-guarded features without a new extension flag, that will, in turn,
>>> inform the GHC2023 idea.
>>>
>>> I don't have the bandwidth to both work on GHC's type-checker (as I'm
>>> doing weekly, as Simon and I coordinate) and push such a thing through.
>>> Though if no one else wants to land that document, I think it's worth my
>>> slowing down type-checker work for a few weeks to do so. So any other
>>> volunteers here? Sorry to redirect us from the immediate task at hand --
>>> GHC2023 -- but one of my principles is that it's best to work out
>>> principles (i.e. our policy on extensions) before specifics.
>>>
>>> Richard
>>>
>>> On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>>> wrote:
>>>
>>> Empirically, I don't feel quite ready to make a call for GHC2023. So I
>>> think that I'd favour a 3-year cadence.
>>>
>>> On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
>>>> >
>>>> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
>>>> > do we want" and then move on to discuss features individually.  At
>>>> > the moment I might think "yes, extension X belongs in the next
>>>> > GHC20xx", so do I vote yes or no for X?
>>>>
>>>> Ah, I see the confusion. The question is _not_ about “the next
>>>> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
>>>> answer may well be “no extension is pressing enough to make a release
>>>> now”.
>>>>
>>>> A year ago we concluded to
>>>>
>>>> > don’t work on defining GHC2022, and the next update
>>>> > will be GHC2023 (or later).
>>>>
>>>> and now we have to decide if it’s going to be GHC2023 or later.
>>>>
>>>> Maybe what I want to say is that by deciding whether we have GHC2023 or
>>>> not, we are (implicitly) setting a precedence for what could become a
>>>> regular cadence, should we not change our minds in the following years.
>>>>
>>>>
>>>> > What do other members of the committee think about cadence?  RSVP!
>>>> > You are a member!
>>>>
>>>> I’m also curious :-)
>>>>
>>>> Cheers,
>>>> Joachim
>>>> --
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de
>>>>   http://www.joachim-breitner.de/
>>>>
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>>>
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230112/6cf111d7/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 19 09:10:31 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 19 Jan 2023 09:10:31 +0000
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
Message-ID: <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>

Dear GHC Steering Committee

Joachim wrote to us ten days ago recommending acceptance of #555.  No one
has responded.

Would you like to respond, please?  (I think this is an easy one.)

Thanks

Simon

On Tue, 10 Jan 2023 at 11:17, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> Jaro Reinders and Simon PJ propose to allow  Higher Order Patterns in
> Rewrite
> Rules.
>
> The idea, by way of an example,
>
>    {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}
>
> will now not only match "foo (\y. negate y + negate y)" (with f set to
> negate)
> but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).
>
> Here "f y" is a higher-order pattern, which are restricted to a
> _pattern_ variable followed by a list of _local_ variable, indicating
> which variable the matched expression may depend on (previously, only
> closed expressions could be matched).
>
> An implementation is sitting ready at
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343
>
> The design was carefully crafted to be backward-compatible and not
> introduce spurious etwa-expansion where there was non before.
>
> It is not guarded by a LANGUAGE pragma (but RULES themselves are not).
> Library authors who care about backward compat will have to deal with
> CPP pragmas.
>
>
> I’m a big fan of rewrite rules, and the proposal is straight forward
> and provides a feature that I'd maybe optimistically already assumed to
> be there already. Therefore, I’m recommending acceptance.
>
> If you disagree please speak up within two weeks, or speed up the
> process by indicating agreement earlier.
>
> 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/20230119/1c91f37f/attachment.html>

From chris at chrisdornan.com  Thu Jan 19 14:51:31 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 14:51:31 +0000
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
 <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
Message-ID: <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>

I am sorry for not getting back sooner Joachim, 

I agree, rewrite rules are cool and this is clearly a useful generalisation.

I vote in favour.

A small suggestion when crafting instructions to us -- do not under any circumstances, ever, give us the option of doing nothing! You will be taken up on it (which is a sad reflection os us, not you). :-)

Chris

> On 2023-01-19, at 09:10, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Dear GHC Steering Committee
> 
> Joachim wrote to us ten days ago recommending acceptance of #555.  No one has responded.
> 
> Would you like to respond, please?  (I think this is an easy one.)
> 
> Thanks
> 
> Simon
> 
> On Tue, 10 Jan 2023 at 11:17, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> Jaro Reinders and Simon PJ propose to allow  Higher Order Patterns in Rewrite
> Rules.
> 
> The idea, by way of an example,
> 
>    {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}
> 
> will now not only match "foo (\y. negate y + negate y)" (with f set to negate)
> but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).
> 
> Here "f y" is a higher-order pattern, which are restricted to a
> _pattern_ variable followed by a list of _local_ variable, indicating
> which variable the matched expression may depend on (previously, only
> closed expressions could be matched).
> 
> An implementation is sitting ready at
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343>
> 
> The design was carefully crafted to be backward-compatible and not
> introduce spurious etwa-expansion where there was non before.
> 
> It is not guarded by a LANGUAGE pragma (but RULES themselves are not).
> Library authors who care about backward compat will have to deal with
> CPP pragmas.
> 
> 
> I’m a big fan of rewrite rules, and the proposal is straight forward
> and provides a feature that I'd maybe optimistically already assumed to
> be there already. Therefore, I’m recommending acceptance.
> 
> If you disagree please speak up within two weeks, or speed up the
> process by indicating agreement earlier.
> 
> 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
> 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/20230119/37f72fcf/attachment.html>

From mail at joachim-breitner.de  Thu Jan 19 15:12:13 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 19 Jan 2023 16:12:13 +0100
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
 <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
 <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
Message-ID: <dfe4e003e811acfb44cb58959897a3c0d66c08aa.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 19.01.2023 um 14:51 +0000 schrieb Chris Dornan:
> I vote in favour.

Thanks :-)

> A small suggestion when crafting instructions to us -- do not under
> any circumstances, ever, give us the option of doing nothing! You
> will be taken up on it (which is a sad reflection os us, not you). :-
> )

Well, in this case silence means silent consent after two weeks, the
secret pill of our committee’s productivity… I’m not overly concerned
about lack of nods for rather straightforward proposals within the
first two weeks, but I am a bit worried about the other 9 proposals
that have been lingering for much longer in pending shepherd or pending
committee decisions…

See
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+shepherd+recommendation%22
https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+label%3A%22Pending+committee+review%22
for the lists (assuming the labels are up-to-date; they are not
always), or the last Status Update email.

Cheers,
Joachim


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


From chris at chrisdornan.com  Thu Jan 19 15:28:37 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 15:28:37 +0000
Subject: [ghc-steering-committee] please accept "Make Symbol a newtype over
	String"
Message-ID: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>

While we are at it, here is another proposal that I think should be straightforward.

Oleg has proposed that we do essentially the same trick Richard proposed to unify Nat and Natural, but with Symbol and String.

Specifically, he is proposing that we replace @data Symbol@ with @newtype Symbol = MkSymbol String at . I won't try and encapsulate any further -- the original is concise and clear.

  * Oleg's "Make Symbol a newtype over String" proposal: https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst
  * For comparison, Richard's accepted "Unify Nat and Natural" proposal: https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst

I suggest we allow the usual two weeks to speak or forever hold your peace.

Chris

From chris at chrisdornan.com  Thu Jan 19 15:31:17 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 15:31:17 +0000
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <dfe4e003e811acfb44cb58959897a3c0d66c08aa.camel@joachim-breitner.de>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
 <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
 <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
 <dfe4e003e811acfb44cb58959897a3c0d66c08aa.camel@joachim-breitner.de>
Message-ID: <EC0773DE-8B82-441A-9ECF-BC65F5E1C6D7@chrisdornan.com>

> Well, in this case silence means silent consent after two weeks, the
> secret pill of our committee’s productivity… I’m not overly concerned
> about lack of nods for rather straightforward proposals within the
> first two weeks, but I am a bit worried about the other 9 proposals
> that have been lingering for much longer in pending shepherd or pending
> committee decisions…

Yes, I quite agree -- and have used that same formulation for accepting "Make Symbol a newtype over String".

Chris



From arnaud.spiwack at tweag.io  Thu Jan 19 15:31:24 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 19 Jan 2023 16:31:24 +0100
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
 <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
 <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
Message-ID: <CAGwnsnn186u0mafGYLMmP_TXm4j8EAG+OpOYsTgpCt8TMU1Gqw@mail.gmail.com>

Hello all, I'm back for real this time,

The proposal (link https://github.com/ghc-proposals/ghc-proposals/pull/555
) is quite reasonable. I think that, in general, higher order patterns are
an uncontroversial extension to rewrite rules (it could be extended further
but if I remember correctly, there are choices there).

I've got a question though: is the following rewrite rule something I can
write in Haskell today?

```
{- RULES … forall f g. map (\x -> f (g x)) = map f . map g
```

In this rule `f (g x)` is not a pattern (because `g` is not rigid). And it
is not clear to me how purely syntactic unification and pattern unification
interact.

I think the automatic addition of lambdas is likely to be fairly innocuous
(despite the fact that it may change `undefined` into, say, `\x y ->
undefined y x`): it happens under lambdas already, so it's unlikely to
effectively change the behaviour of program unbeknownst to the rule author.
I'm sure someone will eventually manage to be bitten by it. But I think
that it's an ok compromise.

/Arnaud

On Thu, 19 Jan 2023 at 15:51, Chris Dornan <chris at chrisdornan.com> wrote:

> I am sorry for not getting back sooner Joachim,
>
> I agree, rewrite rules are cool and this is clearly a useful
> generalisation.
>
> I vote in favour.
>
> A small suggestion when crafting instructions to us -- do not under any
> circumstances, ever, give us the option of doing nothing! You will be taken
> up on it (which is a sad reflection os us, not you). :-)
>
> Chris
>
> On 2023-01-19, at 09:10, Simon Peyton Jones <simon.peytonjones at gmail.com>
> wrote:
>
> Dear GHC Steering Committee
>
> Joachim wrote to us ten days ago recommending acceptance of #555.  No one
> has responded.
>
> Would you like to respond, please?  (I think this is an easy one.)
>
> Thanks
>
> Simon
>
> On Tue, 10 Jan 2023 at 11:17, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Dear Committee,
>>
>> Jaro Reinders and Simon PJ propose to allow  Higher Order Patterns in
>> Rewrite
>> Rules.
>>
>> The idea, by way of an example,
>>
>>    {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}
>>
>> will now not only match "foo (\y. negate y + negate y)" (with f set to
>> negate)
>> but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).
>>
>> Here "f y" is a higher-order pattern, which are restricted to a
>> _pattern_ variable followed by a list of _local_ variable, indicating
>> which variable the matched expression may depend on (previously, only
>> closed expressions could be matched).
>>
>> An implementation is sitting ready at
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343
>>
>> The design was carefully crafted to be backward-compatible and not
>> introduce spurious etwa-expansion where there was non before.
>>
>> It is not guarded by a LANGUAGE pragma (but RULES themselves are not).
>> Library authors who care about backward compat will have to deal with
>> CPP pragmas.
>>
>>
>> I’m a big fan of rewrite rules, and the proposal is straight forward
>> and provides a feature that I'd maybe optimistically already assumed to
>> be there already. Therefore, I’m recommending acceptance.
>>
>> If you disagree please speak up within two weeks, or speed up the
>> process by indicating agreement earlier.
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230119/8c57c15a/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Jan 19 15:44:17 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 19 Jan 2023 16:44:17 +0100
Subject: [ghc-steering-committee] Proposal #532: Clean up and simplify
 the treatment of implicit bindings. Recommendation: partially accept
 (maybe)
In-Reply-To: <CAJKmMz_4UL09CO+W+0ByQ815G0DwEr+uu-bxL3nt0kfS6_WQ+A@mail.gmail.com>
References: <CAGwnsn=8_AwmLka7MfpMiBshwNuEHyh8Yh5KzH3ATU8n2FhSEg@mail.gmail.com>
 <CAJKmMz_4UL09CO+W+0ByQ815G0DwEr+uu-bxL3nt0kfS6_WQ+A@mail.gmail.com>
Message-ID: <CAGwnsnk9Bz_D=Tj68Qbv4G4CJg7ObKaGDHbK+ZFBvhZaizfwZw@mail.gmail.com>

The way I understand the proposal is that the change in phrasing of the
Explicit Binding Principle is largely the addition of “unambiguously” in
the sentence

> every implicit form of variable binding must have an explicit equivalent
that, regardless of the context, is unambiguously a binding site.

This unambiguousness is specifically the realm of the Lexical Scoping
Principle. I don't find this change useful.


(in parallel, John Ericson has proposed a call with some of us to clarify
the details and answer Simon's interogation, it hasn't been set up yet)

/Arnaud


On Wed, 21 Dec 2022 at 16:44, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The new Explicit Binding Principle is now somewhat stronger, in that it
>> requires that there is a form with an explicit binder which “regardless of
>> the context, is unambiguously a binding site”.  The Lexical Binding
>> Principle is changed, as well, to refer to this new change but it's not
>> substantial.
>>
>> I personally don't think this change to the principles is valuable, it
>> simply blurs the distinction between the Explicit Binding Principle and the
>> Lexical Binding Principle.
>>
>
> I don't get this.  Why is the EBP stronger?  Example?  I don't see why the
> distinction is blurred.
>
> The changes to the principles seem fine to me -- modest but useful
> clarifications, no change in semantics.
>
> I don't think I fully understand the second part about flags etc.  My head
> spins.
>
> I wish there was a compact summary of the actual changes proposed. I'll
> ask John for that.
>
> Simon
>
> On Wed, 14 Dec 2022 at 07:09, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> Proposal https://github.com/ghc-proposals/ghc-proposals/pull/532
>> Rendered link for the proposal (although several other files are
>> modified):
>> https://github.com/Ericson2314/ghc-proposals/blob/type-variables/proposals/0532-type-variable-scoping.rst
>>
>> John Ericson proposes to amend Richard's recent Modern Scoped Type
>> Variables Proposal [
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0448-type-variable-scoping.rst
>> ]
>>
>> There are two essential parts to the change:
>> 1. The Explicit Binding Principle is modified
>> 2. Change the two extensions introduced by Proposal #285 [
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0285-no-implicit-binds.rst
>> ], -XImplicitForalls and -XPatternSignatureBinds (so that they can be
>> deactivated), and consolidated in Richard's proposal (where
>> -XPatternSignatureBinds is turned into a binding) into a single
>> -XImplicitBinds extension
>>
>> ---------
>>
>> The new Explicit Binding Principle is now somewhat stronger, in that it
>> requires that there is a form with an explicit binder which “regardless of
>> the context, is unambiguously a binding site”.  The Lexical Binding
>> Principle is changed, as well, to refer to this new change but it's not
>> substantial.
>>
>> I personally don't think this change to the principles is valuable, it
>> simply blurs the distinction between the Explicit Binding Principle and the
>> Lexical Binding Principle. I find the current phrasing more useful. And I
>> don't think the semantics of the conjunction is actually changed. So I
>> recommend that we reject the changes to the Principles.
>>
>> ------------
>>
>> John makes a good point: `-XPatternSignature` being a warning has a
>> limitation. This is pointed out in section “Unified Namespacing and
>> extension monotonicity” of the patch to the Modern Scoped Type Variables
>> Proposal. Namely that  in
>>
>> t = Int
>> (x :: t) = 0
>>
>> The current semantics is to have `t` be a binder (because `t` is not
>> bound in the type namespace). If we add a warning for pattern signatures
>> binders, `t` will still be a binder. But we are starting to introduce a new
>> semantics where failing to lookup `t` in the type namespace, we will fall
>> back to look it up in the term namespace instead. The current semantics of
>> considering `t` a binder in this case is at odds with the fallback
>> strategy. (crucially for this recommendation, the same issue occurs in
>> signatures where `forall`-s are implicitly inferred)
>>
>> (Context: At the time where #285 was proposed, I was in favour of a
>> single extension. Simon PJ strongly pushed for two extensions.)
>>
>> My inclination today is that we have a choice: we can either
>> - consider the problem above to be a serious issue, in which case we
>> probably want to eventually deprecate both implicit foralls and pattern
>> signature binds. If this is the case, then they should be gated behind an
>> extension (see also the discussion on the meaning of extensions that we're
>> currently having). I find it healthy to have a single extension for both
>> features because the problem that the extension is solving is the same,
>> hence, in this case, I recommend accepting the changes.
>> - be happy that the semantics is a little quirky, with the fallback
>> happening only when an explicit forall is specified (and never in pattern
>> signatures). In which case both should probably be warnings, it makes sense
>> for the warnings to be separate categories as these are two different
>> features. In this case I recommend rejection of the proposed changes.
>>
>> ------------
>>
>> I realise I'm leaving a big choice hanging. It's a big decision, I think,
>> which we should weigh carefully (which is kind of funny because the
>> proposed change itself is rather small).
>>
>> Personally, I'd be happy with all implicit foralls and pattern signature
>> binds to be deprecated (so I'm actually taking a position I guess). But I'm
>> not sure that it's super realistic considering the quantity of Haskell that
>> has been written so far. I imagine that there are millions of implicit
>> foralls on Hackage.
>>
>> PS: I'll be on holiday for the next three weeks (starting on Friday
>> night), so you'll have a little while to debate this while I'm away.
>> _______________________________________________
>> 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/20230119/0d919129/attachment.html>

From simon.peytonjones at gmail.com  Thu Jan 19 15:46:42 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 19 Jan 2023 15:46:42 +0000
Subject: [ghc-steering-committee] please accept "Make Symbol a newtype
 over String"
In-Reply-To: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>
References: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>
Message-ID: <CAJKmMz8P9XChX1MgpnR0dvLKr_asxu950vVD08RLTwT9gk7d_Q@mail.gmail.com>

> Oleg has proposed that we do essentially the same trick Richard proposed
to unify Nat and Natural, but with Symbol and String.

Well... not quite. I have commented on the proposal
https://github.com/ghc-proposals/ghc-proposals/pull/562

Simon

On Thu, 19 Jan 2023 at 15:28, Chris Dornan <chris at chrisdornan.com> wrote:

> While we are at it, here is another proposal that I think should be
> straightforward.
>
> Oleg has proposed that we do essentially the same trick Richard proposed
> to unify Nat and Natural, but with Symbol and String.
>
> Specifically, he is proposing that we replace @data Symbol@ with @newtype
> Symbol = MkSymbol String at . I won't try and encapsulate any further -- the
> original is concise and clear.
>
>   * Oleg's "Make Symbol a newtype over String" proposal:
> https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst
>   * For comparison, Richard's accepted "Unify Nat and Natural" proposal:
> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
>
> I suggest we allow the usual two weeks to speak or forever hold your peace.
>
> Chris
> _______________________________________________
> 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/20230119/c9094445/attachment.html>

From chris at chrisdornan.com  Thu Jan 19 16:07:54 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 16:07:54 +0000
Subject: [ghc-steering-committee] please accept "Make Symbol a newtype
 over String"
In-Reply-To: <CAJKmMz8P9XChX1MgpnR0dvLKr_asxu950vVD08RLTwT9gk7d_Q@mail.gmail.com>
References: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>
 <CAJKmMz8P9XChX1MgpnR0dvLKr_asxu950vVD08RLTwT9gk7d_Q@mail.gmail.com>
Message-ID: <1C09E8C7-EC8A-4298-A4EF-18F74E4D3649@chrisdornan.com>

And I have replied -- anybody with views on how we do this should checkout out the discussions at https://github.com/ghc-proposals/ghc-proposals/pull/562#issuecomment-1397214914

> On 2023-01-19, at 15:46, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> > Oleg has proposed that we do essentially the same trick Richard proposed to unify Nat and Natural, but with Symbol and String. 
> 
> Well... not quite. I have commented on the proposal
> https://github.com/ghc-proposals/ghc-proposals/pull/562 <https://github.com/ghc-proposals/ghc-proposals/pull/562>
> 
> Simon
> 
> On Thu, 19 Jan 2023 at 15:28, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
> While we are at it, here is another proposal that I think should be straightforward.
> 
> Oleg has proposed that we do essentially the same trick Richard proposed to unify Nat and Natural, but with Symbol and String.
> 
> Specifically, he is proposing that we replace @data Symbol@ with @newtype Symbol = MkSymbol String at . I won't try and encapsulate any further -- the original is concise and clear.
> 
>   * Oleg's "Make Symbol a newtype over String" proposal: https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst <https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst>
>   * For comparison, Richard's accepted "Unify Nat and Natural" proposal: https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst <https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst>
> 
> I suggest we allow the usual two weeks to speak or forever hold your peace.
> 
> Chris
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

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

From mail at joachim-breitner.de  Thu Jan 19 16:10:59 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 19 Jan 2023 17:10:59 +0100
Subject: [ghc-steering-committee]   GHC Steering Committee Status
Message-ID: <5db026dd3c4689d5c158f7310b23e773cc07ad1c.camel@joachim-breitner.de>

Dear Committee,

it seems we need a reminder what’s on our respective plates, so prompted by
Simon let’s do another status update. I strongly assume you are always reading
these (rare!) emails, especially the second half that lists all our collective
or individual TODO items.

So what has happened since the last one?

 * The discussion whether we should have GHC2023 did not take off really,
   and forked into a somewhat useful, but unfinished fundamental discussion about
   the role of extensions, over at
   https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit

   I’ll kick off a vote about GHC2023 in a few days (and by popular request I’ll
   simplify it to the simple question of whether we should have it at all; I get
   the feeling that my preference for frequent-over-big-changes is not shared and
   no need to vote on individual extensions if it won’t come that too)

 * we were asked to review these proposals:
  
   #523: let in types and patterns, Shepherd: Adam
   #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 

 * we have a recommendation from the shepherd about:

   #512: NoFieldSelectors as datatype annotations, Rec: reject
   #270: Support pun-free code. Recommendation: accept
   #546: Make Symbol a newtype over String, Rec: accept
   #555: Higher Order Patterns in Rewrite Rules, Rec: accept

 * we have sent the following proposals back to revision

   #330: Decorate exceptions with backtrace information

 * we decided about the following proposals

   #541: Warning pragma with categories  (accept)
   #522: Or patterns (accept)

 * the authors retracted their proposal

   #523: let in types and patterns, Shepherd: Adam

We currently have to act on the following 10 proposals, two down
from last time, but still high:

## Waiting for committee decision

#270: Support pun-free code, Shepherd: Chris
      2022-01-01: Assigned to Chris
      2022-08-24: Chris suggests acceptance
      2022-12-04: Chris suggests acceptance again
      2022-12-15: Last message
      I’ve paged out where we are on this one.
      Something with ExplicitNamespaces?

#532: Clean up implicit binding, Shepherd: Arnaud   
      2022-08-23: Assigned to Arnaud
      Sent back for revision
      2022-11-27: Resubmitted
      2022-12-14: Arnaud recommends acceptance
      Arnaud just picked up the conversation again.
      Please make it converge.

#515: Relaxing HasField constraints
      2022-08-01: Assigned to Tom
      2022-08-10: Tom suggests acceptance
      Tom, please drive this forward!

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assignd to Baldur
      2022-10-02: Reassignd to Vlad
      2022-11-30: Vlad recommends rejection
      Turned into a discussion of Modifiers.
      Where are we on this one?

#555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 
      2023-01-10: Acceptance recommended
      Mostly silence. I expect to merge this in a week or so.

#546: Make Symbol a newtype over String, Shepherd: Chris
      2022-11-18: Assigned to Chris
      2022-09-12: Authors gave up
      2023-01-19: Chris revived (as #562) and rec’s acceptance


## Waiting for shepherd recommendation

#526: Applicative Comprehensions, Shepherd: Simon M
      2022-10-08: Assigned to Simon M

#529: Template Haskell quotes as patterns, Shepherd: Adam
      2022-11-16: Assigned to Adam
      (should this be “needs revision”)?

#540: parallelism semaphores, Shepherd: Eric 
      2022-11-08: Assigned to Adam
      2022-11-17: Re-assigned to Eric


#556: fix signature scoping #448, Shepherd: Richard
      2022-11-27: Assigned to Richard

Cheers,
Joachim




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


From simon.peytonjones at gmail.com  Thu Jan 19 16:30:03 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 19 Jan 2023 16:30:03 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <5db026dd3c4689d5c158f7310b23e773cc07ad1c.camel@joachim-breitner.de>
References: <5db026dd3c4689d5c158f7310b23e773cc07ad1c.camel@joachim-breitner.de>
Message-ID: <CAJKmMz-kuwoVT-hRt=jf=ut+rr1nw=zQb3ehdRJn-rPBg_Xxwg@mail.gmail.com>

Shepherds: can I urge you to make progress on your proposals?  It's bad
when things like in our inbox for months.  We should say
yes/no/please-revise in a timely manner.

If you can't do that, please say, and we'll figure something out.

Thank you!

Simon

On Thu, 19 Jan 2023 at 16:11, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> it seems we need a reminder what’s on our respective plates, so prompted by
> Simon let’s do another status update. I strongly assume you are always
> reading
> these (rare!) emails, especially the second half that lists all our
> collective
> or individual TODO items.
>
> So what has happened since the last one?
>
>  * The discussion whether we should have GHC2023 did not take off really,
>    and forked into a somewhat useful, but unfinished fundamental
> discussion about
>    the role of extensions, over at
>
> https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit
>
>    I’ll kick off a vote about GHC2023 in a few days (and by popular
> request I’ll
>    simplify it to the simple question of whether we should have it at all;
> I get
>    the feeling that my preference for frequent-over-big-changes is not
> shared and
>    no need to vote on individual extensions if it won’t come that too)
>
>  * we were asked to review these proposals:
>
>    #523: let in types and patterns, Shepherd: Adam
>    #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim
>
>  * we have a recommendation from the shepherd about:
>
>    #512: NoFieldSelectors as datatype annotations, Rec: reject
>    #270: Support pun-free code. Recommendation: accept
>    #546: Make Symbol a newtype over String, Rec: accept
>    #555: Higher Order Patterns in Rewrite Rules, Rec: accept
>
>  * we have sent the following proposals back to revision
>
>    #330: Decorate exceptions with backtrace information
>
>  * we decided about the following proposals
>
>    #541: Warning pragma with categories  (accept)
>    #522: Or patterns (accept)
>
>  * the authors retracted their proposal
>
>    #523: let in types and patterns, Shepherd: Adam
>
> We currently have to act on the following 10 proposals, two down
> from last time, but still high:
>
> ## Waiting for committee decision
>
> #270: Support pun-free code, Shepherd: Chris
>       2022-01-01: Assigned to Chris
>       2022-08-24: Chris suggests acceptance
>       2022-12-04: Chris suggests acceptance again
>       2022-12-15: Last message
>       I’ve paged out where we are on this one.
>       Something with ExplicitNamespaces?
>
> #532: Clean up implicit binding, Shepherd: Arnaud
>       2022-08-23: Assigned to Arnaud
>       Sent back for revision
>       2022-11-27: Resubmitted
>       2022-12-14: Arnaud recommends acceptance
>       Arnaud just picked up the conversation again.
>       Please make it converge.
>
> #515: Relaxing HasField constraints
>       2022-08-01: Assigned to Tom
>       2022-08-10: Tom suggests acceptance
>       Tom, please drive this forward!
>
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>       2022-09-03: Assignd to Baldur
>       2022-10-02: Reassignd to Vlad
>       2022-11-30: Vlad recommends rejection
>       Turned into a discussion of Modifiers.
>       Where are we on this one?
>
> #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim
>       2023-01-10: Acceptance recommended
>       Mostly silence. I expect to merge this in a week or so.
>
> #546: Make Symbol a newtype over String, Shepherd: Chris
>       2022-11-18: Assigned to Chris
>       2022-09-12: Authors gave up
>       2023-01-19: Chris revived (as #562) and rec’s acceptance
>
>
> ## Waiting for shepherd recommendation
>
> #526: Applicative Comprehensions, Shepherd: Simon M
>       2022-10-08: Assigned to Simon M
>
> #529: Template Haskell quotes as patterns, Shepherd: Adam
>       2022-11-16: Assigned to Adam
>       (should this be “needs revision”)?
>
> #540: parallelism semaphores, Shepherd: Eric
>       2022-11-08: Assigned to Adam
>       2022-11-17: Re-assigned to Eric
>
>
> #556: fix signature scoping #448, Shepherd: Richard
>       2022-11-27: 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/20230119/225374d3/attachment.html>

From chris at chrisdornan.com  Thu Jan 19 19:58:37 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 19:58:37 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <CAJKmMz-kuwoVT-hRt=jf=ut+rr1nw=zQb3ehdRJn-rPBg_Xxwg@mail.gmail.com>
References: <5db026dd3c4689d5c158f7310b23e773cc07ad1c.camel@joachim-breitner.de>
 <CAJKmMz-kuwoVT-hRt=jf=ut+rr1nw=zQb3ehdRJn-rPBg_Xxwg@mail.gmail.com>
Message-ID: <42946CEB-7FDA-4236-BB66-58F0B9D3A595@chrisdornan.com>

Thanks Joachim,

These updates are read carefully and very much appreciated.

This is just to say that I am actively pushing for a resolution of Proposal #270: Support pun-free code. Just to remind everyone, Adam (completely correctly in my view) vetoed the proposal in its current form.

I am trying to contact Artyom to discuss the next steps. He doesn't provide any public contact details on GitHub -- does anybody have an email address handy? I am trying a couple of communication channels but a direct email address would be really helpful.

I wanted to talk to Artyom directly before asking him to do anything because I really want his input in deciding what we do next. I very much want to save the proposal and I think, viewed correctly, it has been highly successful in illuminating several issues that need illumination, has a useful extension related to warnings that we can accept right now.

I have changed the status to _Needs revision_ and will let you know when anything changes.

Chris


> On 2023-01-19, at 16:30, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> Shepherds: can I urge you to make progress on your proposals?  It's bad when things like in our inbox for months.  We should say yes/no/please-revise in a timely manner.
> 
> If you can't do that, please say, and we'll figure something out.
> 
> Thank you! 
> 
> Simon
> 
> On Thu, 19 Jan 2023 at 16:11, Joachim Breitner <mail at joachim-breitner.de> wrote:
> Dear Committee,
> 
> it seems we need a reminder what’s on our respective plates, so prompted by
> Simon let’s do another status update. I strongly assume you are always reading
> these (rare!) emails, especially the second half that lists all our collective
> or individual TODO items.
> 
> So what has happened since the last one?
> 
>  * The discussion whether we should have GHC2023 did not take off really,
>    and forked into a somewhat useful, but unfinished fundamental discussion about
>    the role of extensions, over at
>    https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit
> 
>    I’ll kick off a vote about GHC2023 in a few days (and by popular request I’ll
>    simplify it to the simple question of whether we should have it at all; I get
>    the feeling that my preference for frequent-over-big-changes is not shared and
>    no need to vote on individual extensions if it won’t come that too)
> 
>  * we were asked to review these proposals:
> 
>    #523: let in types and patterns, Shepherd: Adam
>    #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 
> 
>  * we have a recommendation from the shepherd about:
> 
>    #512: NoFieldSelectors as datatype annotations, Rec: reject
>    #270: Support pun-free code. Recommendation: accept
>    #546: Make Symbol a newtype over String, Rec: accept
>    #555: Higher Order Patterns in Rewrite Rules, Rec: accept
> 
>  * we have sent the following proposals back to revision
> 
>    #330: Decorate exceptions with backtrace information
> 
>  * we decided about the following proposals
> 
>    #541: Warning pragma with categories  (accept)
>    #522: Or patterns (accept)
> 
>  * the authors retracted their proposal
> 
>    #523: let in types and patterns, Shepherd: Adam
> 
> We currently have to act on the following 10 proposals, two down
> from last time, but still high:
> 
> ## Waiting for committee decision
> 
> #270: Support pun-free code, Shepherd: Chris
>       2022-01-01: Assigned to Chris
>       2022-08-24: Chris suggests acceptance
>       2022-12-04: Chris suggests acceptance again
>       2022-12-15: Last message
>       I’ve paged out where we are on this one.
>       Something with ExplicitNamespaces?
> 
> #532: Clean up implicit binding, Shepherd: Arnaud   
>       2022-08-23: Assigned to Arnaud
>       Sent back for revision
>       2022-11-27: Resubmitted
>       2022-12-14: Arnaud recommends acceptance
>       Arnaud just picked up the conversation again.
>       Please make it converge.
> 
> #515: Relaxing HasField constraints
>       2022-08-01: Assigned to Tom
>       2022-08-10: Tom suggests acceptance
>       Tom, please drive this forward!
> 
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>       2022-09-03: Assignd to Baldur
>       2022-10-02: Reassignd to Vlad
>       2022-11-30: Vlad recommends rejection
>       Turned into a discussion of Modifiers.
>       Where are we on this one?
> 
> #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 
>       2023-01-10: Acceptance recommended
>       Mostly silence. I expect to merge this in a week or so.
> 
> #546: Make Symbol a newtype over String, Shepherd: Chris
>       2022-11-18: Assigned to Chris
>       2022-09-12: Authors gave up
>       2023-01-19: Chris revived (as #562) and rec’s acceptance
> 
> 
> ## Waiting for shepherd recommendation
> 
> #526: Applicative Comprehensions, Shepherd: Simon M
>       2022-10-08: Assigned to Simon M
> 
> #529: Template Haskell quotes as patterns, Shepherd: Adam
>       2022-11-16: Assigned to Adam
>       (should this be “needs revision”)?
> 
> #540: parallelism semaphores, Shepherd: Eric 
>       2022-11-08: Assigned to Adam
>       2022-11-17: Re-assigned to Eric
> 
> 
> #556: fix signature scoping #448, Shepherd: Richard
>       2022-11-27: 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 chris at chrisdornan.com  Thu Jan 19 20:27:04 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 19 Jan 2023 20:27:04 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <42946CEB-7FDA-4236-BB66-58F0B9D3A595@chrisdornan.com>
References: <5db026dd3c4689d5c158f7310b23e773cc07ad1c.camel@joachim-breitner.de>
 <CAJKmMz-kuwoVT-hRt=jf=ut+rr1nw=zQb3ehdRJn-rPBg_Xxwg@mail.gmail.com>
 <42946CEB-7FDA-4236-BB66-58F0B9D3A595@chrisdornan.com>
Message-ID: <DE76366A-57ED-47A0-9561-9FD5783EE659@chrisdornan.com>

Just a quick update to say that my attempts to connect with Artyom re #270 have born fruit and we are now exchanging emails.

Chris

> On 2023-01-19, at 19:58, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> Thanks Joachim,
> 
> These updates are read carefully and very much appreciated.
> 
> This is just to say that I am actively pushing for a resolution of Proposal #270: Support pun-free code. Just to remind everyone, Adam (completely correctly in my view) vetoed the proposal in its current form.
> 
> I am trying to contact Artyom to discuss the next steps. He doesn't provide any public contact details on GitHub -- does anybody have an email address handy? I am trying a couple of communication channels but a direct email address would be really helpful.
> 
> I wanted to talk to Artyom directly before asking him to do anything because I really want his input in deciding what we do next. I very much want to save the proposal and I think, viewed correctly, it has been highly successful in illuminating several issues that need illumination, has a useful extension related to warnings that we can accept right now.
> 
> I have changed the status to _Needs revision_ and will let you know when anything changes.
> 
> Chris
> 
> 
>> On 2023-01-19, at 16:30, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> 
>> Shepherds: can I urge you to make progress on your proposals?  It's bad when things like in our inbox for months.  We should say yes/no/please-revise in a timely manner.
>> 
>> If you can't do that, please say, and we'll figure something out.
>> 
>> Thank you! 
>> 
>> Simon
>> 
>> On Thu, 19 Jan 2023 at 16:11, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> Dear Committee,
>> 
>> it seems we need a reminder what’s on our respective plates, so prompted by
>> Simon let’s do another status update. I strongly assume you are always reading
>> these (rare!) emails, especially the second half that lists all our collective
>> or individual TODO items.
>> 
>> So what has happened since the last one?
>> 
>> * The discussion whether we should have GHC2023 did not take off really,
>>   and forked into a somewhat useful, but unfinished fundamental discussion about
>>   the role of extensions, over at
>>   https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit
>> 
>>   I’ll kick off a vote about GHC2023 in a few days (and by popular request I’ll
>>   simplify it to the simple question of whether we should have it at all; I get
>>   the feeling that my preference for frequent-over-big-changes is not shared and
>>   no need to vote on individual extensions if it won’t come that too)
>> 
>> * we were asked to review these proposals:
>> 
>>   #523: let in types and patterns, Shepherd: Adam
>>   #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 
>> 
>> * we have a recommendation from the shepherd about:
>> 
>>   #512: NoFieldSelectors as datatype annotations, Rec: reject
>>   #270: Support pun-free code. Recommendation: accept
>>   #546: Make Symbol a newtype over String, Rec: accept
>>   #555: Higher Order Patterns in Rewrite Rules, Rec: accept
>> 
>> * we have sent the following proposals back to revision
>> 
>>   #330: Decorate exceptions with backtrace information
>> 
>> * we decided about the following proposals
>> 
>>   #541: Warning pragma with categories  (accept)
>>   #522: Or patterns (accept)
>> 
>> * the authors retracted their proposal
>> 
>>   #523: let in types and patterns, Shepherd: Adam
>> 
>> We currently have to act on the following 10 proposals, two down
>> from last time, but still high:
>> 
>> ## Waiting for committee decision
>> 
>> #270: Support pun-free code, Shepherd: Chris
>>      2022-01-01: Assigned to Chris
>>      2022-08-24: Chris suggests acceptance
>>      2022-12-04: Chris suggests acceptance again
>>      2022-12-15: Last message
>>      I’ve paged out where we are on this one.
>>      Something with ExplicitNamespaces?
>> 
>> #532: Clean up implicit binding, Shepherd: Arnaud   
>>      2022-08-23: Assigned to Arnaud
>>      Sent back for revision
>>      2022-11-27: Resubmitted
>>      2022-12-14: Arnaud recommends acceptance
>>      Arnaud just picked up the conversation again.
>>      Please make it converge.
>> 
>> #515: Relaxing HasField constraints
>>      2022-08-01: Assigned to Tom
>>      2022-08-10: Tom suggests acceptance
>>      Tom, please drive this forward!
>> 
>> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>>      2022-09-03: Assignd to Baldur
>>      2022-10-02: Reassignd to Vlad
>>      2022-11-30: Vlad recommends rejection
>>      Turned into a discussion of Modifiers.
>>      Where are we on this one?
>> 
>> #555: Higher Order Patterns in Rewrite Rules, Shepherd Joachim 
>>      2023-01-10: Acceptance recommended
>>      Mostly silence. I expect to merge this in a week or so.
>> 
>> #546: Make Symbol a newtype over String, Shepherd: Chris
>>      2022-11-18: Assigned to Chris
>>      2022-09-12: Authors gave up
>>      2023-01-19: Chris revived (as #562) and rec’s acceptance
>> 
>> 
>> ## Waiting for shepherd recommendation
>> 
>> #526: Applicative Comprehensions, Shepherd: Simon M
>>      2022-10-08: Assigned to Simon M
>> 
>> #529: Template Haskell quotes as patterns, Shepherd: Adam
>>      2022-11-16: Assigned to Adam
>>      (should this be “needs revision”)?
>> 
>> #540: parallelism semaphores, Shepherd: Eric 
>>      2022-11-08: Assigned to Adam
>>      2022-11-17: Re-assigned to Eric
>> 
>> 
>> #556: fix signature scoping #448, Shepherd: Richard
>>      2022-11-27: 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 adam at well-typed.com  Thu Jan 19 20:35:41 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 19 Jan 2023 20:35:41 +0000
Subject: [ghc-steering-committee] please accept "Make Symbol a newtype
 over String"
In-Reply-To: <1C09E8C7-EC8A-4298-A4EF-18F74E4D3649@chrisdornan.com>
References: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>
 <CAJKmMz8P9XChX1MgpnR0dvLKr_asxu950vVD08RLTwT9gk7d_Q@mail.gmail.com>
 <1C09E8C7-EC8A-4298-A4EF-18F74E4D3649@chrisdornan.com>
Message-ID: <fdd19ce9-59b1-c0a9-73a4-acde601b16ed@well-typed.com>

Thanks for reviving this proposal, Chris. I support acceptance (and am 
happy to set aside the alternative of `type Symbol = String`, which is 
distinctly less compelling than `type Nat = Natural`).

Adam


On 19/01/2023 16:07, Chris Dornan wrote:
> And I have replied -- anybody with views on how we do this should 
> checkout out the discussions at 
> https://github.com/ghc-proposals/ghc-proposals/pull/562#issuecomment-1397214914 <https://github.com/ghc-proposals/ghc-proposals/pull/562#issuecomment-1397214914>
> 
>> On 2023-01-19, at 15:46, Simon Peyton Jones 
>> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>> wrote:
>>
>> > Oleg has proposed that we do essentially the same trick Richard 
>> proposed to unify Nat and Natural, but with Symbol and String.
>>
>> Well... not quite. I have commented on the proposal
>> https://github.com/ghc-proposals/ghc-proposals/pull/562 
>> <https://github.com/ghc-proposals/ghc-proposals/pull/562>
>>
>> Simon
>>
>> On Thu, 19 Jan 2023 at 15:28, Chris Dornan <chris at chrisdornan.com 
>> <mailto:chris at chrisdornan.com>> wrote:
>>
>>     While we are at it, here is another proposal that I think should
>>     be straightforward.
>>
>>     Oleg has proposed that we do essentially the same trick Richard
>>     proposed to unify Nat and Natural, but with Symbol and String.
>>
>>     Specifically, he is proposing that we replace @data Symbol@ with
>>     @newtype Symbol = MkSymbol String at . I won't try and encapsulate
>>     any further -- the original is concise and clear.
>>
>>       * Oleg's "Make Symbol a newtype over String" proposal:
>>     https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst <https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst>
>>       * For comparison, Richard's accepted "Unify Nat and Natural"
>>     proposal:
>>     https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst <https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst>
>>
>>     I suggest we allow the usual two weeks to speak or forever hold
>>     your peace.
>>
>>     Chris

-- 
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 adam at well-typed.com  Thu Jan 19 21:28:51 2023
From: adam at well-typed.com (Adam Gundry)
Date: Thu, 19 Jan 2023 21:28:51 +0000
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <CAGwnsnn186u0mafGYLMmP_TXm4j8EAG+OpOYsTgpCt8TMU1Gqw@mail.gmail.com>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
 <CAJKmMz-MYKkpQWU8n5o15VCyf11a11nwPwvv2chKkBYNBfiUwA@mail.gmail.com>
 <32CDCBB7-53F5-4E92-B43E-614E2CAA06D3@chrisdornan.com>
 <CAGwnsnn186u0mafGYLMmP_TXm4j8EAG+OpOYsTgpCt8TMU1Gqw@mail.gmail.com>
Message-ID: <3497ee12-cd70-50d5-cbd4-232ecaabeaa2@well-typed.com>

This is a very well-written proposal. I support acceptance.


On 19/01/2023 15:31, Arnaud Spiwack wrote:
> I've got a question though: is the following rewrite rule something I 
> can write in Haskell today?
> 
> ```
> {- RULES … forall f g. map (\x -> f (g x)) = map f . map g
> ```
> 
> In this rule `f (g x)` is not a pattern (because `g` is not rigid). And 
> it is not clear to me how purely syntactic unification and pattern 
> unification interact.

I believe you can write this today, but the template `f (g x)` will 
match only a target with an explicit application where the argument is 
itself an explicit application (e.g. `e1 (e2 x)`).

Under the proposal, `f (g x)` is not in the pattern fragment so it will 
match only an explicit application, but `g x` is a pattern so the 
argument is allowed to be more general, e.g. the template `f (g x)` will 
match `e1 x` or `e1 (e2 x 42 x)`.

At least, this is how I understood the proposal, but I may have 
misinterpreted. The specification could be slightly clearer about how 
this works (in particular the "Ambiguity breaking" point). I've 
commented to that effect on the PR.

Adam


> On Thu, 19 Jan 2023 at 15:51, Chris Dornan <chris at chrisdornan.com 
> <mailto:chris at chrisdornan.com>> wrote:
> 
>     I am sorry for not getting back sooner Joachim,
> 
>     I agree, rewrite rules are cool and this is clearly a useful
>     generalisation.
> 
>     I vote in favour.
> 
>     A small suggestion when crafting instructions to us -- do not under
>     any circumstances, ever, give us the option of doing nothing! You
>     will be taken up on it (which is a sad reflection os us, not you). :-)
> 
>     Chris
> 
>>     On 2023-01-19, at 09:10, Simon Peyton Jones
>>     <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
>>     wrote:
>>
>>     Dear GHC Steering Committee
>>
>>     Joachim wrote to us ten days ago recommending acceptance of #555. 
>>     No one has responded.
>>
>>     Would you like to respond, please?  (I think this is an easy one.)
>>
>>     Thanks
>>
>>     Simon
>>
>>     On Tue, 10 Jan 2023 at 11:17, Joachim Breitner
>>     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>
>>         Dear Committee,
>>
>>         Jaro Reinders and Simon PJ propose to allow  Higher Order
>>         Patterns in Rewrite
>>         Rules.
>>
>>         The idea, by way of an example,
>>
>>            {-# RULES forall f.  foo  (\y. f y + f y) = bar f #-}
>>
>>         will now not only match "foo (\y. negate y + negate y)" (with
>>         f set to negate)
>>         but also "foo (\y. y*y + y*y)" (with f set to (\x. x*x)).
>>
>>         Here "f y" is a higher-order pattern, which are restricted to a
>>         _pattern_ variable followed by a list of _local_ variable,
>>         indicating
>>         which variable the matched expression may depend on
>>         (previously, only
>>         closed expressions could be matched).
>>
>>         An implementation is sitting ready at
>>         https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343
>>         <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9343>
>>
>>         The design was carefully crafted to be backward-compatible and not
>>         introduce spurious etwa-expansion where there was non before.
>>
>>         It is not guarded by a LANGUAGE pragma (but RULES themselves
>>         are not).
>>         Library authors who care about backward compat will have to
>>         deal with
>>         CPP pragmas.
>>
>>
>>         I’m a big fan of rewrite rules, and the proposal is straight
>>         forward
>>         and provides a feature that I'd maybe optimistically already
>>         assumed to
>>         be there already. Therefore, I’m recommending acceptance.
>>
>>         If you disagree please speak up within two weeks, or speed up the
>>         process by indicating agreement earlier.
>>
>>         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 arnaud.spiwack at tweag.io  Fri Jan 20 08:04:42 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 20 Jan 2023 09:04:42 +0100
Subject: [ghc-steering-committee] please accept "Make Symbol a newtype
 over String"
In-Reply-To: <fdd19ce9-59b1-c0a9-73a4-acde601b16ed@well-typed.com>
References: <CC664840-05BB-4793-9343-52FACF927850@chrisdornan.com>
 <CAJKmMz8P9XChX1MgpnR0dvLKr_asxu950vVD08RLTwT9gk7d_Q@mail.gmail.com>
 <1C09E8C7-EC8A-4298-A4EF-18F74E4D3649@chrisdornan.com>
 <fdd19ce9-59b1-c0a9-73a4-acde601b16ed@well-typed.com>
Message-ID: <CAGwnsnkNBQMjus=kNtVuCBF1OYkqX_1+WjKkxh668GbWND6Csw@mail.gmail.com>

Dear all,

I struggle to have an opinion on these proposals on whether we should unify
Nat/Natural, Symbol/String etc…

But in this particular case, and as I've written in the proposal's thread,
I fail to see how the proposed change addresses its motivations. So I'm
leaning toward rejection right now.

/Arnaud

On Thu, 19 Jan 2023 at 21:36, Adam Gundry <adam at well-typed.com> wrote:

> Thanks for reviving this proposal, Chris. I support acceptance (and am
> happy to set aside the alternative of `type Symbol = String`, which is
> distinctly less compelling than `type Nat = Natural`).
>
> Adam
>
>
> On 19/01/2023 16:07, Chris Dornan wrote:
> > And I have replied -- anybody with views on how we do this should
> > checkout out the discussions at
> >
> https://github.com/ghc-proposals/ghc-proposals/pull/562#issuecomment-1397214914
> <
> https://github.com/ghc-proposals/ghc-proposals/pull/562#issuecomment-1397214914
> >
> >
> >> On 2023-01-19, at 15:46, Simon Peyton Jones
> >> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at gmail.com>>
> wrote:
> >>
> >> > Oleg has proposed that we do essentially the same trick Richard
> >> proposed to unify Nat and Natural, but with Symbol and String.
> >>
> >> Well... not quite. I have commented on the proposal
> >> https://github.com/ghc-proposals/ghc-proposals/pull/562
> >> <https://github.com/ghc-proposals/ghc-proposals/pull/562>
> >>
> >> Simon
> >>
> >> On Thu, 19 Jan 2023 at 15:28, Chris Dornan <chris at chrisdornan.com
> >> <mailto:chris at chrisdornan.com>> wrote:
> >>
> >>     While we are at it, here is another proposal that I think should
> >>     be straightforward.
> >>
> >>     Oleg has proposed that we do essentially the same trick Richard
> >>     proposed to unify Nat and Natural, but with Symbol and String.
> >>
> >>     Specifically, he is proposing that we replace @data Symbol@ with
> >>     @newtype Symbol = MkSymbol String at . I won't try and encapsulate
> >>     any further -- the original is concise and clear.
> >>
> >>       * Oleg's "Make Symbol a newtype over String" proposal:
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst
> <
> https://github.com/ghc-proposals/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst
> >
> >>       * For comparison, Richard's accepted "Unify Nat and Natural"
> >>     proposal:
> >>
> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
> <
> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
> >
> >>
> >>     I suggest we allow the usual two weeks to speak or forever hold
> >>     your peace.
> >>
> >>     Chris
>
> --
> 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/20230120/10912f05/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Jan 20 08:13:25 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 20 Jan 2023 09:13:25 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
 <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
 <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>
 <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>
Message-ID: <CAGwnsnk_Kv-rRRHnPknS-NqF=2161U7FdUPLWDMdzVLxMPr5SA@mail.gmail.com>

> Arnaud might be another possible driving force to getting it done?
>

I can if you need me to. If you ask me to take the lead on this, I'll need
a bit of time to come up with a good way of driving consensus. It seems to
be a rather tricky subject :-) .
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230120/ceb0c10f/attachment.html>

From simon.peytonjones at gmail.com  Fri Jan 20 08:26:35 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 20 Jan 2023 08:26:35 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAGwnsnk_Kv-rRRHnPknS-NqF=2161U7FdUPLWDMdzVLxMPr5SA@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
 <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>
 <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>
 <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>
 <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>
 <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>
 <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>
 <fab678769a57daeb59cef5688775515c19e27d00.camel@joachim-breitner.de>
 <A243A3D5-5085-4FB5-B7E7-B36DC72047FA@chrisdornan.com>
 <CAJKmMz95cO8E8y7Vgyx3ERwFoefWA+=y0OWn3KKeN_FZ-tLzKQ@mail.gmail.com>
 <2ab2fd7ff8e91d3d43370e9d5c695810c2940f43.camel@joachim-breitner.de>
 <CAJKmMz9EtEN2CJoHjUed2pqExXSCHZuOMi+n9cz-yJ9Z-6DzwQ@mail.gmail.com>
 <e81b632c724bd088cb7f2bd8f49a490b267989d8.camel@joachim-breitner.de>
 <CAGwnsnn77HT+hFDkAxKc1ukBe62awRzDMk=wYzT1pQ2BD69RyQ@mail.gmail.com>
 <010f0185a104198d-92d8ddef-aaea-4e62-8bea-0ceab5f6f726-000000@us-east-2.amazonses.com>
 <CANsrgP+Z=+xsBAMWJVN9+DDcCmEVaYZ1SW0fP7Diu45DV23jAg@mail.gmail.com>
 <CAJKmMz_DGdaQLhzuQr5ktX-MHqPWGqqP+OF7=A5sXo9Dh6+NAQ@mail.gmail.com>
 <CAGwnsnk_Kv-rRRHnPknS-NqF=2161U7FdUPLWDMdzVLxMPr5SA@mail.gmail.com>
Message-ID: <CAJKmMz-bdioH4gHGoa5fY34eMpTQy4EX_tVH7p=W+rUdMS7f1Q@mail.gmail.com>

Thank you Arnaud!

Simon

On Fri, 20 Jan 2023 at 08:14, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
> Arnaud might be another possible driving force to getting it done?
>>
>
> I can if you need me to. If you ask me to take the lead on this, I'll need
> a bit of time to come up with a good way of driving consensus. It seems to
> be a rather tricky subject :-) .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230120/c56aa6af/attachment.html>

From mail at joachim-breitner.de  Sun Jan 22 12:40:11 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 22 Jan 2023 13:40:11 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
Message-ID: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>

Hi Committee,

as ~threatened~ announced, I’m calling for a vote on whether we should
proceed to define the next GHC20xx _now_, as GHC2023, or wait for a
year.

Judging from the silence around the PR for GHC2023 I deduce that the
appetite for GHC2023 is generally low, and will not bother you with
complicated looking questions about which extensions might make GHC2023
worth it in an attempt to parallelize the “whether” with the “what”.

Instead, please cast your vote until Apri 5 (but preferrably earlier)
on the question:

  Should we proceed towards GHC2023?

(If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay
quiet until next fall.)

I am intentionally not asking for a fixed cadence at this point. We
have made but one release so far, and it seems presumptious to try to
predict what makes most sense next year, or the next four years to
come.

(I’ll follow up with my vote and justification separately.)

Cheers,
Joachim



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


From mail at joachim-breitner.de  Sun Jan 22 12:57:11 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 22 Jan 2023 13:57:11 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
Message-ID: <58f7356f4f90eb314f65e03d081b0deb470d5208.camel@joachim-breitner.de>

Hi,

unsurprisingly, I vote

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
>   Should we proceed towards GHC2023?

Yes!


Brief summary of why:

 * One goal of GHC20xx was to fix one problem we had with the
   Haskell20xx process: New releases were rare, small and eventually
   stopped. So I want GHC20xx to not fall in the same trap of being
   over-cautious when making releases.

 * A early and small(!) (e.g. just adding role annotations) release 
   gives both us and the community a chance to practice. It is a good
   way to learn that new GHC20xx releases are _not_ a big deal, and
   those users who upgrade will learn that upgrading is (well, can be)
   totally painless. I’d like to let them have such a positive
   experience.

 * Assuming that every GHC20xx is “better” in some sense than the 
   previous, and even if it is just mild QoL improvements, I see little
   gain in holding that back longer than necessary.

 * GHC20xx releases are lower pain than GHC releases or base changes!

   A new version of GHC you _have_ to upgrade to get important fixes. 
   A new version of base you _have_ to upgrade to, else you cannot get
   new versions of your dependencies. These upgrades are forced on the
   user, with only limited wiggle room.

   A new GHC20xx is totally optional. Your -XGHC2021 code will just 
   continue to work as you upgrade GHC. So if it is _less_ disruptive,
   why have a longer cadence?

   Or, as a friend of mine nicely put it: Even if there are users out 
   there that are best served by having GHC2021, GHC2024, GHC2027…, 
   they are free and welcome to only bump their edition every three
   years. Also having GHC2023 and GHC2025 … does not in any way impact
   them.

   So because of their opt-in, usually-pinned nature, backward compat
   worries need not restrict us here, I’d say.
  

Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I
wouldn’t worry about a _fixed_ cadence until we had two or three
releases and learned from it.

Cheers,
Joachim


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


From chris at chrisdornan.com  Sun Jan 22 13:11:22 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 22 Jan 2023 13:11:22 +0000
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <58f7356f4f90eb314f65e03d081b0deb470d5208.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <58f7356f4f90eb314f65e03d081b0deb470d5208.camel@joachim-breitner.de>
Message-ID: <CFDE04B6-78E6-4693-93D5-C3604F87636F@chrisdornan.com>

I agree that we should release GHC2023 for all the reason Joachim says. Each GHCXXXX release is just our declaration of the extensions that we think should be enabled by default. It is going to change as we larn more about the extensions, let's clean as we go and make an annual statement of our recommended Haskell brew. If we are not prepared to spend a bit of time thinking about whether we recommend extensions we have already defined then that, to me, suggests something is off.

What do you say Joachim to publishing schedule for proposing additions (and deletions) and then voting on them. I was think we could take the year but having a 9.8-friendly schedule makes sense.

Anyway my vote is for yes to GHC2023.

Chris

> On 2023-01-22, at 12:57, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> unsurprisingly, I vote
> 
> Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
>>   Should we proceed towards GHC2023?
> 
> Yes!
> 
> 
> Brief summary of why:
> 
> * One goal of GHC20xx was to fix one problem we had with the
>   Haskell20xx process: New releases were rare, small and eventually
>   stopped. So I want GHC20xx to not fall in the same trap of being
>   over-cautious when making releases.
> 
> * A early and small(!) (e.g. just adding role annotations) release 
>   gives both us and the community a chance to practice. It is a good
>   way to learn that new GHC20xx releases are _not_ a big deal, and
>   those users who upgrade will learn that upgrading is (well, can be)
>   totally painless. I’d like to let them have such a positive
>   experience.
> 
> * Assuming that every GHC20xx is “better” in some sense than the 
>   previous, and even if it is just mild QoL improvements, I see little
>   gain in holding that back longer than necessary.
> 
> * GHC20xx releases are lower pain than GHC releases or base changes!
> 
>   A new version of GHC you _have_ to upgrade to get important fixes. 
>   A new version of base you _have_ to upgrade to, else you cannot get
>   new versions of your dependencies. These upgrades are forced on the
>   user, with only limited wiggle room.
> 
>   A new GHC20xx is totally optional. Your -XGHC2021 code will just 
>   continue to work as you upgrade GHC. So if it is _less_ disruptive,
>   why have a longer cadence?
> 
>   Or, as a friend of mine nicely put it: Even if there are users out 
>   there that are best served by having GHC2021, GHC2024, GHC2027…, 
>   they are free and welcome to only bump their edition every three
>   years. Also having GHC2023 and GHC2025 … does not in any way impact
>   them.
> 
>   So because of their opt-in, usually-pinned nature, backward compat
>   worries need not restrict us here, I’d say.
> 
> 
> Hence I’d like to define a GHC2023 (in time for GHC 9.8?). And I
> wouldn’t worry about a _fixed_ cadence until we had two or three
> releases and learned from it.
> 
> 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 vlad.z.4096 at gmail.com  Sun Jan 22 23:20:52 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 23 Jan 2023 02:20:52 +0300
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <CFDE04B6-78E6-4693-93D5-C3604F87636F@chrisdornan.com>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <58f7356f4f90eb314f65e03d081b0deb470d5208.camel@joachim-breitner.de>
 <CFDE04B6-78E6-4693-93D5-C3604F87636F@chrisdornan.com>
Message-ID: <CAHZ0NLrxVFX7fYbkqpmmckuOeBcKs=QNj7_99KHHT0QxDgE=VQ@mail.gmail.com>

I vote against frequent language editions for two reasons:
* We shouldn't change our mind about the recommended extensions so often
* We shouldn't overwhelm the user with unnecessary choice (which edition is
best?)

Right now it's down to Haskell98, Haskell2010, and GHC2021, which is good.
Each added option makes things worse. GHC2021 turned out quite well, let's
stick to it for a while and see how Haskell evolves in the next five to ten
years.

- Vlad

On Sun, Jan 22, 2023 at 4:11 PM Chris Dornan <chris at chrisdornan.com> wrote:

> I agree that we should release GHC2023 for all the reason Joachim says.
> Each GHCXXXX release is just our declaration of the extensions that we
> think should be enabled by default. It is going to change as we larn more
> about the extensions, let's clean as we go and make an annual statement of
> our recommended Haskell brew. If we are not prepared to spend a bit of time
> thinking about whether we recommend extensions we have already defined then
> that, to me, suggests something is off.
>
> What do you say Joachim to publishing schedule for proposing additions
> (and deletions) and then voting on them. I was think we could take the year
> but having a 9.8-friendly schedule makes sense.
>
> Anyway my vote is for yes to GHC2023.
>
> Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230123/16491977/attachment.html>

From mail at joachim-breitner.de  Mon Jan 23 07:42:07 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Jan 2023 08:42:07 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <CAHZ0NLrxVFX7fYbkqpmmckuOeBcKs=QNj7_99KHHT0QxDgE=VQ@mail.gmail.com>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <58f7356f4f90eb314f65e03d081b0deb470d5208.camel@joachim-breitner.de>
 <CFDE04B6-78E6-4693-93D5-C3604F87636F@chrisdornan.com>
 <CAHZ0NLrxVFX7fYbkqpmmckuOeBcKs=QNj7_99KHHT0QxDgE=VQ@mail.gmail.com>
Message-ID: <c887157245c57719a8812c49261d40f61cedfa08.camel@joachim-breitner.de>

Hi,

> GHC2021 turned out quite
> well, let's stick to it for a while and see how Haskell evolves in
> the next five to ten years.

that’s an interesting take. For me it was always clear that GHC20xx is
meant to be a continuous process (with yet to determined cadence), but
you are proposing that GHC2021 (not …xx!) could be, for now, the final
product? That’s certainly a valid position as well, but not one that
achieves the goals we (or at least I) had when coming up with the
GHC20xx.

Am Montag, dem 23.01.2023 um 02:20 +0300 schrieb Vladislav Zavialov:
> * We shouldn't change our mind about the recommended extensions so
> often

I don’t think it’s changing our mind. It’s a natural process of
stabilization and maturization that two years later some more
extensions have been proven to be good enough to no longer be
extensions, but simply be Haskell.

Also, we make mistakes. Over on the PR Oleg makes an excellent argument
why a language with Data.Safe.coerce and GeneralisedNewtypeDeriving
really also needs role annotations. I’d like to be able to fix my
mistakes.

> * We shouldn't overwhelm the user with unnecessary choice (which
> edition is best?)
>
> Right now it's down to Haskell98, Haskell2010, and GHC2021, which is
> good. Each added option makes things worse.

I disagree. Once we have, say, GHC2021, GHC2023 and GHC2024 out there.
Then these are not equally valid options, no more than programmers
currently decide whether to use text-0, text-1, or text-2. Like there,
our GHC20xx numbers are _versions_, and at least for new projects
hopefully nobody should ever have to pick an older version than the
newest supported by their GHC.

It is a good point, however, that we need to communicate that, and
present it in the users’s guide accordingly. For example, document the
latest prominently, and the others in a separate section “previous
language editions”. And maybe also document “on-by-default features
(default  since GHC20xx, can be disabled with -XNo…)” and actual
“extensions” separately.

(I agree that more options are bad, thus my motivation for GHC20xx is
to _reduce_ options that programmers have to make: by reducing the
number of language extensions they have to decide about!)

Cheers,
Joachim


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


From mail at joachim-breitner.de  Mon Jan 23 07:43:03 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Jan 2023 08:43:03 +0100
Subject: [ghc-steering-committee] #555: Higher Order Patterns in Rewrite
 Rules, rec accept
In-Reply-To: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
References: <d7a04b41b0d9c0412e5eb3490076a2694af29c36.camel@joachim-breitner.de>
Message-ID: <bc3e46c61d6f386265b3011577a2b964e61b990a.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 10.01.2023 um 12:17 +0100 schrieb Joachim Breitner:
> Therefore, I’m recommending acceptance.
> 

since I got only positive or no feedback, I’m marking this as accepted.

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


From arnaud.spiwack at tweag.io  Mon Jan 23 08:22:31 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 23 Jan 2023 09:22:31 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
Message-ID: <CAGwnsnma9z_A0C=yJm4VWCNK5oOOK4aLqs1LQSwYC3yt-jkYTQ@mail.gmail.com>

>   Should we proceed towards GHC2023?
>

I don't feel very strongly either way. Am I allowed to be a pain and vote
“weak wait”? That'd be my inclination.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230123/d98870d1/attachment.html>

From simon.peytonjones at gmail.com  Mon Jan 23 08:36:30 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 23 Jan 2023 08:36:30 +0000
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
Message-ID: <CAJKmMz9hYqyFLfW7ReCaXqZrHwzBq1YG_6xn6rei=4Rbuez_5g@mail.gmail.com>

I vote we wait until at least 2024.

Simon

On Sun, 22 Jan 2023 at 12:40, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi Committee,
>
> as ~threatened~ announced, I’m calling for a vote on whether we should
> proceed to define the next GHC20xx _now_, as GHC2023, or wait for a
> year.
>
> Judging from the silence around the PR for GHC2023 I deduce that the
> appetite for GHC2023 is generally low, and will not bother you with
> complicated looking questions about which extensions might make GHC2023
> worth it in an attempt to parallelize the “whether” with the “what”.
>
> Instead, please cast your vote until Apri 5 (but preferrably earlier)
> on the question:
>
>   Should we proceed towards GHC2023?
>
> (If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay
> quiet until next fall.)
>
> I am intentionally not asking for a fixed cadence at this point. We
> have made but one release so far, and it seems presumptious to try to
> predict what makes most sense next year, or the next four years to
> come.
>
> (I’ll follow up with my vote and justification separately.)
>
> 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/20230123/5cec122c/attachment.html>

From mail at joachim-breitner.de  Mon Jan 23 14:24:26 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Jan 2023 15:24:26 +0100
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
Message-ID: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>

Hi,

our current by-law kinda bind our hands in case some motivated comes
along and would like to join the committee, and Simon PJ suggested that
we should give us the discretion to hold membership votes out-of-season
as well. The suggested wording change is in
https://github.com/ghc-proposals/ghc-proposals/pull/572

Please discuss and cast your vote within two weeks (preferably earlier,
as you can guess this change is not happening completely out of the
blue.)

I’m in favor.

Cheers,
Joachim


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


From vlad.z.4096 at gmail.com  Mon Jan 23 16:32:30 2023
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Mon, 23 Jan 2023 19:32:30 +0300
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
In-Reply-To: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
References: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
Message-ID: <CAHZ0NLqGqwE3NZ8ySqGSpmB_LLJT6Oh1ZLKmWRzm3HUiib=k_g@mail.gmail.com>

In favor

On Mon, Jan 23, 2023, 17:24 Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> our current by-law kinda bind our hands in case some motivated comes
> along and would like to join the committee, and Simon PJ suggested that
> we should give us the discretion to hold membership votes out-of-season
> as well. The suggested wording change is in
> https://github.com/ghc-proposals/ghc-proposals/pull/572
>
> Please discuss and cast your vote within two weeks (preferably earlier,
> as you can guess this change is not happening completely out of the
> blue.)
>
> I’m in favor.
>
> 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/20230123/0e7157ad/attachment.html>

From chris at chrisdornan.com  Mon Jan 23 18:27:22 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 23 Jan 2023 18:27:22 +0000
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
In-Reply-To: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
References: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
Message-ID: <FFD1BC26-3BAE-4F2F-96AA-79C0EC89CFDF@chrisdornan.com>

+1 to this proposed change to the nominations process.

> On 2023-01-23, at 14:24, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> our current by-law kinda bind our hands in case some motivated comes
> along and would like to join the committee, and Simon PJ suggested that
> we should give us the discretion to hold membership votes out-of-season
> as well. The suggested wording change is in
> https://github.com/ghc-proposals/ghc-proposals/pull/572
> 
> Please discuss and cast your vote within two weeks (preferably earlier,
> as you can guess this change is not happening completely out of the
> blue.)
> 
> I’m in favor.
> 
> 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 adam at well-typed.com  Mon Jan 23 20:38:30 2023
From: adam at well-typed.com (Adam Gundry)
Date: Mon, 23 Jan 2023 20:38:30 +0000
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <CAJKmMz9hYqyFLfW7ReCaXqZrHwzBq1YG_6xn6rei=4Rbuez_5g@mail.gmail.com>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <CAJKmMz9hYqyFLfW7ReCaXqZrHwzBq1YG_6xn6rei=4Rbuez_5g@mail.gmail.com>
Message-ID: <aafa4a35-0a70-35f7-5e37-d188b5ef5576@well-typed.com>

I vote we proceed with GHC2023.

There are inconsistencies in GHC2021 that would be better to sort out 
sooner rather than later (e.g. the fact that GADTs snuck in through the 
back door, with GADTSyntax and ExistentialQuantification both included 
but neither GADTs nor MonoLocalBinds). That's entirely understandable, 
given that it was a first attempt at something new, but I don't see why 
we shouldn't make some small improvements in the next iteration.

Adam


On 23/01/2023 08:36, Simon Peyton Jones wrote:
> I vote we wait until at least 2024.
> 
> Simon
> 
> On Sun, 22 Jan 2023 at 12:40, Joachim Breitner <mail at joachim-breitner.de 
> <mailto:mail at joachim-breitner.de>> wrote:
> 
>     Hi Committee,
> 
>     as ~threatened~ announced, I’m calling for a vote on whether we should
>     proceed to define the next GHC20xx _now_, as GHC2023, or wait for a
>     year.
> 
>     Judging from the silence around the PR for GHC2023 I deduce that the
>     appetite for GHC2023 is generally low, and will not bother you with
>     complicated looking questions about which extensions might make GHC2023
>     worth it in an attempt to parallelize the “whether” with the “what”.
> 
>     Instead, please cast your vote until Apri 5 (but preferrably earlier)
>     on the question:
> 
>        Should we proceed towards GHC2023?
> 
>     (If yay wins we’ll refine #559 and vote on that. If nay wins, I’ll stay
>     quiet until next fall.)
> 
>     I am intentionally not asking for a fixed cadence at this point. We
>     have made but one release so far, and it seems presumptious to try to
>     predict what makes most sense next year, or the next four years to
>     come.
> 
>     (I’ll follow up with my vote and justification separately.)
> 
>     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 lists at richarde.dev  Thu Jan 26 02:02:27 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 26 Jan 2023 02:02:27 +0000
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
In-Reply-To: <FFD1BC26-3BAE-4F2F-96AA-79C0EC89CFDF@chrisdornan.com>
References: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
 <FFD1BC26-3BAE-4F2F-96AA-79C0EC89CFDF@chrisdornan.com>
Message-ID: <010f0185ebcfdff5-2cd89938-e3bf-4403-bc1c-8b2e9e89d81b-000000@us-east-2.amazonses.com>

+1 from me, too

> On Jan 23, 2023, at 1:27 PM, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> +1 to this proposed change to the nominations process.
> 
>> On 2023-01-23, at 14:24, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi,
>> 
>> our current by-law kinda bind our hands in case some motivated comes
>> along and would like to join the committee, and Simon PJ suggested that
>> we should give us the discretion to hold membership votes out-of-season
>> as well. The suggested wording change is in
>> https://github.com/ghc-proposals/ghc-proposals/pull/572
>> 
>> Please discuss and cast your vote within two weeks (preferably earlier,
>> as you can guess this change is not happening completely out of the
>> blue.)
>> 
>> I’m in favor.
>> 
>> 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 arnaud.spiwack at tweag.io  Mon Jan 30 08:43:27 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 30 Jan 2023 09:43:27 +0100
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
Message-ID: <CAGwnsnkCXzOERjHBTNsr5xkVw2wCRRXcmLBR8aZuwbAiZBKHWQ@mail.gmail.com>

Spam detection software, running on the system "mail.haskell.org", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  I've posted comments on the Github thread, to try and clarify
   a few points before I cast my vote. On Thu, 26 Jan 2023 at 03:02, Richard
   Eisenberg <lists at richarde.dev> wrote: > Spam detection software, running
  on the system "mail.haskell.org", has > identified this incoming email as
  possible spam. The original message > has been attached to this so you can
   view it (if it isn't spam) or label > similar future email. If you have any
   questions, see > @@CONTACT_ADDRESS@@ for details. > > Content preview: +1
   from me, too > On Jan 23, 2023, at 1:27 PM, Chris > Dornan > <chris at chrisdornan.com>
   wrote: > > +1 to this proposed change to the > nominations > process. > >>
   On 2023-01-23, at 14:24, Joachim Breitner < > mail at joachim-breitner.de> >
   wrote: >> >> Hi, >> >> our current by-law kinda bind our hands in case >
  some > motivated comes >> along and would like to join the committee, and
  Simon > PJ suggested that >> we should give us the discretion to hold membership
   > votes > out-of-season >> as well. The suggested wording change is in >>
   > https://github.com/ghc-proposals/ghc-proposals/pull/572 > >> >> Please
  discuss and cast your vote within two weeks (preferably > earlier, > >> as
   you can guess this change is not happening completely out of the > >> > blue.)
   >> >> I’m in favor. >> >> 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
   > [...] > > Content analysis details: (5.0 points, 5.0 required) > > pts
  rule name description > ---- > > -0.0 SPF_HELO_PASS SPF: HELO matches SPF
  record > 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired
  language > 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
   > > > > > > Forwarded message > From: Richard Eisenberg <lists at richarde.dev>
   > [...] 

Content analysis details:   (5.8 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 SPF_PASS               SPF: sender matches SPF record
 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.8 BAYES_50               BODY: Bayes spam probability is 40 to 60%
                            [score: 0.5000]
 0.0 T_DKIM_INVALID         DKIM-Signature header exists but is not valid

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

-------------- next part --------------
An embedded message was scrubbed...
From: Arnaud Spiwack <arnaud.spiwack at tweag.io>
Subject: Re: [ghc-steering-committee] By-law change: Allow self-nominations
Date: Mon, 30 Jan 2023 09:43:27 +0100
Size: 15000
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230130/5ee2d0cc/attachment.mht>