From simon.peytonjones at gmail.com  Tue Nov  1 11:43:14 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 1 Nov 2022 11:43:14 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
Message-ID: <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>

>
> Another year has passed, and if we are serious with the idea that
> GHC20xx is a continuous thing, we should probably start defining
> GHC2023 – even if it is just a small delta.
>

Indeed, we originally said we'd review GHC20xx annually, but I think we
might want to consult the community to see if that is too often.  There has
been an interesting thread
<https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
Discourse.

The HF Stability Working Group discussed this on Monday, and I think Tom
Ellis (a member of the SWG) is willing to lead a consultation.  I think
that would be great -- we have no axe to grind here, and I think we'll be
delighted to do whatever makes the maximal number of people happy.

Tom (cc'd) will write with more info shortly.  Sound OK?

Simon

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

> Hi Committee,
>
> when we defined the process for GHC20xx, as written in
>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
> we wrote
>
>    Likely, the first iteration of this process will be vastly different
>    from the following ones: The first one is expected to add a large
>    number of uncontroversial extensions; so the next iteration will
>    likely only make a smaller, but more controversial change.
>
>    Therefore, this proposal does not commit to a fixed cadence.
>    Instead, 6 months after the first release of a version of GHC that
>    supports a GHC20xx set, we evaluate the outcome, the process, and
>    the perceived need of a next release. At that time we will refine
>    the processes, if needed, and set a cadence.
>
> The first version of GHC that supported GHC2021 was 9.2, released in
> October 2022.
>
> Last fall we said that not enough time has passed to do such an
> evaluation, and we skipped defining GHC2022.
>
> Another year has passed, and if we are serious with the idea that
> GHC20xx is a continuous thing, we should probably start defining
> GHC2023 – even if it is just a small delta. This e-mail tries to
> kickstart that process.
>
>
> Last time we did a relative elaborate thing where we voted on
> essentially _every_ extension. I think that made sense for the first
> iteration, where we had to winddow down the likely extensions. But now
> we have a base line (GHC2021), and are asked to find a suitable delta,
> and I’d go for a nomination-based approach: Committee members can
> propose adding (or removing, in theory) specific extensions, and then
> we vote only on those. Does that sound reasonable?
>
> Does anyone have any insight from the real world? Has GHC2021 helped
> our users? And if not, why not?
>
> What kind of hard data would you like to see, if any?
>
> (I’m a bit wary of spending too much time writing scripts to scrape
> hackage, for example to see which extensions people tend to enable _in
> addition_ to GHC2021, only to see that libraries on hackage are
> understandably slow to use default-language: GHC2021, as that’s not
> great for backward compat for now. But I am also not sure where to look
> for good data…)
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20221101/f24b5fe0/attachment.html>

From simon.peytonjones at gmail.com  Tue Nov  1 14:07:00 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 1 Nov 2022 14:07:00 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
Message-ID: <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>

Adding Tom Ellis (thank you Jakob).

Simon

On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:

> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta.
>>
>
> Indeed, we originally said we'd review GHC20xx annually, but I think we
> might want to consult the community to see if that is too often.  There has
> been an interesting thread
> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> Discourse.
>
> The HF Stability Working Group discussed this on Monday, and I think Tom
> Ellis (a member of the SWG) is willing to lead a consultation.  I think
> that would be great -- we have no axe to grind here, and I think we'll be
> delighted to do whatever makes the maximal number of people happy.
>
> Tom (cc'd) will write with more info shortly.  Sound OK?
>
> Simon
>
> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi Committee,
>>
>> when we defined the process for GHC20xx, as written in
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>> we wrote
>>
>>    Likely, the first iteration of this process will be vastly different
>>    from the following ones: The first one is expected to add a large
>>    number of uncontroversial extensions; so the next iteration will
>>    likely only make a smaller, but more controversial change.
>>
>>    Therefore, this proposal does not commit to a fixed cadence.
>>    Instead, 6 months after the first release of a version of GHC that
>>    supports a GHC20xx set, we evaluate the outcome, the process, and
>>    the perceived need of a next release. At that time we will refine
>>    the processes, if needed, and set a cadence.
>>
>> The first version of GHC that supported GHC2021 was 9.2, released in
>> October 2022.
>>
>> Last fall we said that not enough time has passed to do such an
>> evaluation, and we skipped defining GHC2022.
>>
>> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta. This e-mail tries to
>> kickstart that process.
>>
>>
>> Last time we did a relative elaborate thing where we voted on
>> essentially _every_ extension. I think that made sense for the first
>> iteration, where we had to winddow down the likely extensions. But now
>> we have a base line (GHC2021), and are asked to find a suitable delta,
>> and I’d go for a nomination-based approach: Committee members can
>> propose adding (or removing, in theory) specific extensions, and then
>> we vote only on those. Does that sound reasonable?
>>
>> Does anyone have any insight from the real world? Has GHC2021 helped
>> our users? And if not, why not?
>>
>> What kind of hard data would you like to see, if any?
>>
>> (I’m a bit wary of spending too much time writing scripts to scrape
>> hackage, for example to see which extensions people tend to enable _in
>> addition_ to GHC2021, only to see that libraries on hackage are
>> understandably slow to use default-language: GHC2021, as that’s not
>> great for backward compat for now. But I am also not sure where to look
>> for good data…)
>>
>> Cheers,
>> Joachim
>>
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> 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/20221101/e57dbe6d/attachment.html>

From arnaud.spiwack at tweag.io  Thu Nov  3 15:19:51 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Nov 2022 16:19:51 +0100
Subject: [ghc-steering-committee] Welcome Adam, welcome back Arnaud
In-Reply-To: <ce4dcb5c9e66322886384f738d7bf0146f344a8b.camel@joachim-breitner.de>
References: <f9ba21f44045faefdef3254cb45b3055077b2db6.camel@joachim-breitner.de>
 <CAJKmMz9665LK+GQh1R_jnqxFy3xyPZYWppznNQQ=59sB5g+auA@mail.gmail.com>
 <0511ebda-b488-a340-a693-cad4b414e2a0@well-typed.com>
 <ce4dcb5c9e66322886384f738d7bf0146f344a8b.camel@joachim-breitner.de>
Message-ID: <CAH6fHQmn32oVnhwwJAuvvLdzD-xKh2cF13KSY3n_BC5xXr4t0w@mail.gmail.com>

Hello again to everybody. Thanks for the welcome-back!

On Mon, Oct 24, 2022 at 9:20 PM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 24.10.2022 um 20:10 +0100 schrieb Adam Gundry:
> > Thank you for the welcome! The one proposal awaiting committee review is
> > one for which I'm a co-author, so I'll keep my authorial hat on for that
> > one. :-)
>
> oh, of course, I only peeked at the first author.
>
> I’m sure we’ll get some proposals to review your way in due time :-)
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20221103/f13f7eba/attachment.html>

From arnaud.spiwack at tweag.io  Thu Nov  3 15:34:02 2022
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 3 Nov 2022 16:34:02 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@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>
Message-ID: <CAH6fHQkPeYDbJ4fMsm6wG4Guiy9XC-JsQMrXPGoAxt9HeGShLw@mail.gmail.com>

We could have a look at the extensions that almost made the cut in 2021 and
autonominate them.

What I would like to nominate myself are:
- SimplifiedSubsumption
- ImpredicativeTypes

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

I haven't had feedback come my way. I do fine GHC2021 quite liberating,
honestly.

On the other hand, there is one annoyance that I found but didn't have time
to investigate: it seems that at least Stack, maybe Cabal, when starting a
ghci process (e.g. for the language server) ends up having a ghci with
GHC2021 turned on, even if the default language for the project is
Haskell2010. This means that you get different error messages in your build
and language server. Even if the programmer is unaware of GHC2021. But it
probably shouldn't affect the current discussion.

On Tue, Nov 1, 2022 at 3:05 PM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Adding Tom Ellis (thank you Jakob).
>
> Simon
>
> On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> Another year has passed, and if we are serious with the idea that
>>> GHC20xx is a continuous thing, we should probably start defining
>>> GHC2023 – even if it is just a small delta.
>>>
>>
>> Indeed, we originally said we'd review GHC20xx annually, but I think we
>> might want to consult the community to see if that is too often.  There has
>> been an interesting thread
>> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
>> Discourse.
>>
>> The HF Stability Working Group discussed this on Monday, and I think Tom
>> Ellis (a member of the SWG) is willing to lead a consultation.  I think
>> that would be great -- we have no axe to grind here, and I think we'll be
>> delighted to do whatever makes the maximal number of people happy.
>>
>> Tom (cc'd) will write with more info shortly.  Sound OK?
>>
>> Simon
>>
>> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi Committee,
>>>
>>> when we defined the process for GHC20xx, as written in
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>>> we wrote
>>>
>>>    Likely, the first iteration of this process will be vastly different
>>>    from the following ones: The first one is expected to add a large
>>>    number of uncontroversial extensions; so the next iteration will
>>>    likely only make a smaller, but more controversial change.
>>>
>>>    Therefore, this proposal does not commit to a fixed cadence.
>>>    Instead, 6 months after the first release of a version of GHC that
>>>    supports a GHC20xx set, we evaluate the outcome, the process, and
>>>    the perceived need of a next release. At that time we will refine
>>>    the processes, if needed, and set a cadence.
>>>
>>> The first version of GHC that supported GHC2021 was 9.2, released in
>>> October 2022.
>>>
>>> Last fall we said that not enough time has passed to do such an
>>> evaluation, and we skipped defining GHC2022.
>>>
>>> Another year has passed, and if we are serious with the idea that
>>> GHC20xx is a continuous thing, we should probably start defining
>>> GHC2023 – even if it is just a small delta. This e-mail tries to
>>> kickstart that process.
>>>
>>>
>>> Last time we did a relative elaborate thing where we voted on
>>> essentially _every_ extension. I think that made sense for the first
>>> iteration, where we had to winddow down the likely extensions. But now
>>> we have a base line (GHC2021), and are asked to find a suitable delta,
>>> and I’d go for a nomination-based approach: Committee members can
>>> propose adding (or removing, in theory) specific extensions, and then
>>> we vote only on those. Does that sound reasonable?
>>>
>>> Does anyone have any insight from the real world? Has GHC2021 helped
>>> our users? And if not, why not?
>>>
>>> What kind of hard data would you like to see, if any?
>>>
>>> (I’m a bit wary of spending too much time writing scripts to scrape
>>> hackage, for example to see which extensions people tend to enable _in
>>> addition_ to GHC2021, only to see that libraries on hackage are
>>> understandably slow to use default-language: GHC2021, as that’s not
>>> great for backward compat for now. But I am also not sure where to look
>>> for good data…)
>>>
>>> Cheers,
>>> Joachim
>>>
>>> --
>>> Joachim Breitner
>>>   mail at joachim-breitner.de
>>>   http://www.joachim-breitner.de/
>>>
>>> _______________________________________________
>>> 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/20221103/039261fd/attachment.html>

From marlowsd at gmail.com  Fri Nov  4 17:10:17 2022
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 4 Nov 2022 17:10:17 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
Message-ID: <CANsrgPLt=_=tBV84Yu6dtZ4Wf=OMVYGvvrJQkMdMbynuJ14k-A@mail.gmail.com>

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

> Does anyone have any insight from the real world?


Yes!


> Has GHC2021 helped
> our users? And if not, why not?
>

Not a bit, because we're still using GHC 8.8 :-)

Having said that, at work we've been using our own version of GHC2021 for
many years now (by just enabling a set of extensions by default in the
build system) and I'm often reminded how much time it saves.

I'm somewhat persuaded by the people on the discourse thread arguing that
if the point is stability, then we should not produce new iterations too
frequently. But what is too frequent?

Cheers
Simon




>
> What kind of hard data would you like to see, if any?
>
> (I’m a bit wary of spending too much time writing scripts to scrape
> hackage, for example to see which extensions people tend to enable _in
> addition_ to GHC2021, only to see that libraries on hackage are
> understandably slow to use default-language: GHC2021, as that’s not
> great for backward compat for now. But I am also not sure where to look
> for good data…)
>
> Cheers,
> Joachim
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20221104/895f8fbb/attachment.html>

From mail at joachim-breitner.de  Sat Nov  5 10:23:14 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 05 Nov 2022 11:23:14 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CANsrgPLt=_=tBV84Yu6dtZ4Wf=OMVYGvvrJQkMdMbynuJ14k-A@mail.gmail.com>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CANsrgPLt=_=tBV84Yu6dtZ4Wf=OMVYGvvrJQkMdMbynuJ14k-A@mail.gmail.com>
Message-ID: <a44edd617394e288b20e6ae2eb49435f207584b9.camel@joachim-breitner.de>

Hi,

Am Freitag, dem 04.11.2022 um 17:10 +0000 schrieb Simon Marlow:
> Having said that, at work we've been using our own version of GHC2021
> for many years now (by just enabling a set of extensions by default
> in the build system) and I'm often reminded how much time it saves.
> 
> I'm somewhat persuaded by the people on the discourse thread arguing
> that if the point is stability, then we should not produce new
> iterations too frequently. But what is too frequent?

I’d say the point is not stability. Or, at least not what some people
might expect from stability… 

The point of the GHC20xx series is to get (proven, useful,
uncontroversial) goodies into the hands of our users _by default_.
Because GHC is actively developed, the set of proven useful
uncontroversial goods of course changes, so expecting stability from
“the latest GHC20xx” is contradictory!

And there are plenty of use cases where such stability isn’t needed.
The one-shot script or GHCi session foremost. But also as an
application developer, I may target one fixed GHC version anyways, and
am happy to have the language evolve (in usually non-disruptive ways
anyways) whenever I upgrade the GHC version I am using.

And those who need more stability (e.g. library authors publishing code
that needs to work with multiple GHC versions) are likely to pin their
default-language anyways, e.g. to GHC2021. And _that_ is stable!

So I think we can define frequent (yearly or twoyearly or whatever
makes sense organically) without compromising those who want stability.


And (as I mentioned elsewhere already), there is an inherent long 
delay between defining GHC20xx and large-scale adoption. I don’t think
that’s a reason to reduce the frequency. If GHC2021 lacks some useful
extension (say, -XDeriveAnotherClass), then we likely want that to be
available as soon as possible. Waiting for GHC2025 just means it’s even
two more years (in addition to the delay) before it reaches our users.


TL;DR: I see nothing wrong with and advocate for defining relatively
frequent and possible small incremental GHC20xx editions.


Cheers,
Joachim



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


From simon.peytonjones at gmail.com  Tue Nov  8 09:07:57 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 8 Nov 2022 09:07:57 +0000
Subject: [ghc-steering-committee] Fwd:  GHC2023
In-Reply-To: <Y2oNcEYd0Iq09Vhb@cloudinit-builder>
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>
Message-ID: <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@mail.gmail.com>

Dear Ghc-Steering-Committee,

Here's an email from Tom Ellis about the GHC20xx thread.  Please do read it.

(Who, if anyone, is the moderator of the ghc-steering-committee mailing
list?)

Simon

---------- Forwarded message ---------
From: Tom Ellis <tom-2019 at jaguarpaw.co.uk>
Date: Tue, 8 Nov 2022 at 08:04
Subject: Re: [ghc-steering-committee] GHC2023
To: Simon Peyton Jones <simon.peytonjones at gmail.com>


Hello Simon, I sent this to the steering committee mailing list on
Saturday but received an email in response saying it was "being held
until the list moderator can review it for approval".  Perhaps no
moderator has had the chance to review it yet, as it hasn't yet
appeared on the mailing list archive

https://mail.haskell.org/pipermail/ghc-steering-committee/2022-November/thread.html#start

Perhaps you would be kind enough to forward it to the list for me
directly.  Thanks, Tom




Thanks Simon.

On reflection, I'm not particularly motivated to consult the community
because the concerns I have impinge most strongly on members of the
community who are distant from where a consultation could easily
reach, and on non-but-potential-members of the community who are
getting a false impression from afar.

I will content myself with elaborating on my concerns and then leaving
it to the steering committee to take them into account if they see
fit.  To set the scene, everything I write below is presented from the
point of view of someone who wishes Haskell usage to increase and
believes that we can't increase Haskell usage by appealing to people
who are already comfortable with the way the Haskell ecosystem
currently works: we've already got most of those people.

For the ten years that I have been in the community, Haskell has had a
(false) reputation, to outsiders, as a fragmented language with
multiple mysterious things called "language extensions" each of which
fractures the language in an incompatible way.  "It's impossible to
learn Haskell because there are so many incompatible Haskells" they
say.  It may be hard to believe that this perception exists: as users
of GHC we know that there are very few extensions that introduce any
incompatibility with others; extensions typically just remove
unneccesary restrictions.  But, for those of you who don't spend
far-too-much of your time on discussion fora such as Hacker News and
Reddit, I can guarantee to you that this objection to Haskell comes up
*a lot*.

Haskell also has, to both insiders and outsiders, a (true) reputation
for being an unstable moving target.  "It's impossible to learn or use
Haskell because the language and libraries keep changing", they say.
This one is easier to believe.

GHC2021 is a wonderful way of dealing with all of the first and part
of the second objection!  I can now respond to complaints of language
fragmentation and language instability by simply saying "Turn on
GHC2021 and be happy".  This is great news!

(GHC2021 doesn't deal with instability in libraries of course, but I'm
pleased that there are many people making efforts in that area too.)

I am concerned that GHC2023 would weaken the power of my rejoinder
"Turn on GHC2021 and be happy".  Now I am at risk of the responses
"But why not GHC2023?", "Haskell introduced a new, incompatible
language just two years after standardising on GHC2021", "I just spent
my precious time learning GHC2021, now I have to spend time learning
GHC2023.".  Sure, these responses are based on misunderstandings of
the technical details.  But perceptions really, really matter!  If we
want a large increase in Haskell usage then we have to take
perceptions into account.  We can't substantially increase Haskell
usage any more by appealing just to our techncial excellence.

If we choose to prioritise business-as-usual, that is, the
incorporation of highly technically excellent features on a regular
basis, with no thought to the costs, then the consequence will be
Haskellers-as-usual: people who value that kind of thing in spite of
the costs.  We already have most of those people.  We can't increase
Haskell adoption that way.  If we choose to change tack then we have
the chance of changing the types of people we pick up as new
Haskellers, from among those who would never otherwise have considered
the language.

To put it pithily, Joachim writes in a sibling thread "The point of
the GHC20xx series is to get (proven, useful, uncontroversial) goodies
into the hands of our users".  Are members of the Haskell community,
and indeed non-but-potential-members, screaming out for new "goodies"?
Or are they screaming out for a brief respite from the unforgiving
churn of the Haskell ecosystem, both real and not-real-but-perceived.
My experience of the last ten years tells me it's the latter.

To be clear, I personally am very much looking forward to more highly
technically excellent features, including the exciting ongoing work on
dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
the community that really inspires and excites me! I personally can
tolerate the churn.  But I don't want those things at the *cost* of
continuing to push away potential new users who are currently peering
over the fence, discouraged because they can't tolerate the churn that
they see, real or perceived.

Now, with my stability hat on, looking from the point of view of
process design, it's actually *better* for changes to happen in small
increments, so maybe having GHC20xx every year is actually *better*
than every five years.  I don't wish to advocate for one choice or
another.  Rather I wish to advocate for the point of view that:

  Technical excellence matters.  Stability and the perception of
  stability matter too.

Tom




On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones at gmail.com>
wrote:
> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta.
>>
>
> Indeed, we originally said we'd review GHC20xx annually, but I think we
> might want to consult the community to see if that is too often.  There
has
> been an interesting thread
> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> Discourse.
>
> The HF Stability Working Group discussed this on Monday, and I think Tom
> Ellis (a member of the SWG) is willing to lead a consultation.  I think
> that would be great -- we have no axe to grind here, and I think we'll be
> delighted to do whatever makes the maximal number of people happy.
>
> Tom (cc'd) will write with more info shortly.  Sound OK?
>
> Simon
>
> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi Committee,
>>
>> when we defined the process for GHC20xx, as written in
>>
>>
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>> we wrote
>>
>>    Likely, the first iteration of this process will be vastly different
>>    from the following ones: The first one is expected to add a large
>>    number of uncontroversial extensions; so the next iteration will
>>    likely only make a smaller, but more controversial change.
>>
>>    Therefore, this proposal does not commit to a fixed cadence.
>>    Instead, 6 months after the first release of a version of GHC that
>>    supports a GHC20xx set, we evaluate the outcome, the process, and
>>    the perceived need of a next release. At that time we will refine
>>    the processes, if needed, and set a cadence.
>>
>> The first version of GHC that supported GHC2021 was 9.2, released in
>> October 2022.
>>
>> Last fall we said that not enough time has passed to do such an
>> evaluation, and we skipped defining GHC2022.
>>
>> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta. This e-mail tries to
>> kickstart that process.
>>
>>
>> Last time we did a relative elaborate thing where we voted on
>> essentially _every_ extension. I think that made sense for the first
>> iteration, where we had to winddow down the likely extensions. But now
>> we have a base line (GHC2021), and are asked to find a suitable delta,
>> and I’d go for a nomination-based approach: Committee members can
>> propose adding (or removing, in theory) specific extensions, and then
>> we vote only on those. Does that sound reasonable?
>>
>> Does anyone have any insight from the real world? Has GHC2021 helped
>> our users? And if not, why not?
>>
>> What kind of hard data would you like to see, if any?
>>
>> (I’m a bit wary of spending too much time writing scripts to scrape
>> hackage, for example to see which extensions people tend to enable _in
>> addition_ to GHC2021, only to see that libraries on hackage are
>> understandably slow to use default-language: GHC2021, as that’s not
>> great for backward compat for now. But I am also not sure where to look
>> for good data…)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221108/51d2852e/attachment.html>

From mail at joachim-breitner.de  Tue Nov  8 11:47:48 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 08 Nov 2022 12:47:48 +0100
Subject: [ghc-steering-committee] Fwd:  GHC2023
In-Reply-To: <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@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>
Message-ID: <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.camel@joachim-breitner.de>

Hi Tom,

thanks for your input! If I may (inadequadly) summarize what I read is
that we should take into account stability and not just technical
stability (your code doesn’t have to change as you upgrade your code),
but also _perceived_ stability (there is GHC2021 and GH2023 and that’s
confused).

I agree that this is imporant, and worth thinking more about.

In particular: How do other languages treat this? In one of my
newsfeeds I recently read

> Version 1.65.0 of the Rust language has been released. Improvements 
> include generic associated types, a new let...else statement, and
> the ability to break from labeled blocks

and also

> Version 3.10.0 of the Python language has been released. There are a 
> lot of significant changes in this release, including the much-
> discussed structural pattern-matching feature.

so these (popular, non-scary) languages certainly don’t freeze their
language, and do extend the language repeatedly. Why are they not
preceived as unstable as Haskell is?

(Here I am really talking about _perceived_ instability, not real
instability in the sense of _breaking_ changes – the above extensions
are AFAIK not breaking, and many of our Haskell extensions are not
breaking.)

It is because we have the concept of a language extension in the first
place! And, on top of that, now the concept of the current version of
GHC Haskell. If we didn’t have that in the first place, and no Haskell
standard, it’d just be the case that GHC-9.2 happens to be the first
version where you can, say, derive Functor, and that’s it.

My idea of GHC20xx is that it brings us closer to the Rust or Python
model: Unless you tell GHC you want something else, you get the latest
stable (in the sense of proven, not in the sense of unchanging) set of
language features.

And if you want something else (e.g. opt-out of new extensions, or try
out experimental ones), you have to explicitly ask for it (e.g. pin the
language version with -XGHC2021, or enable -XFancyTypes). A bit like
using Rust nightly, just less hassle…

So if you don’t actively do something, you get the same experience as
in rust or python … and at this point I wonder why this experience is
perceived as different as in these languages?

(Again, I am focusing here on non-breaking, additive extensions. How to
handle breaking changes is yet another discussion, of course, and one
where peeking at Python or Rust is not always showing us the best way
to do it.)

Cheers,
Joachim




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


From mail at joachim-breitner.de  Tue Nov  8 12:49:53 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 08 Nov 2022 13:49:53 +0100
Subject: [ghc-steering-committee] Please review #540: parallelism semaphores,
 Shepherd: Adam
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>

Dear Committee,

parallelism semaphores
have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering

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

https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst

I suggest Adam shepherds this proposal.

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


Cheers,
Joachim




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


From adam at well-typed.com  Wed Nov  9 21:04:58 2022
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 9 Nov 2022 21:04:58 +0000
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: Adam
In-Reply-To: <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
Message-ID: <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>

Hi,


On 08/11/2022 12:49, Joachim Breitner wrote:
> Dear Committee,
> 
> parallelism semaphores
> have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/540
> 
> https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst
> 
> I suggest Adam shepherds this proposal.

I'm not sure if we have explicit guidelines regarding conflicts of 
interest (should we?), but I think I should declare a conflict in this 
case. The authors of this proposal work for Well-Typed and have proposed 
and implemented this feature on behalf of a client, which might give the 
impression of potential bias.

I am happy to take the advice of the committee on how to handle this 
situation. While I don't think I need to recuse myself from discussion 
of the proposal completely, it seems like it would be better for it to 
be shepherded by someone else?

Cheers,

Adam


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

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

From mail at joachim-breitner.de  Wed Nov  9 21:33:35 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 09 Nov 2022 22:33:35 +0100
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: Adam
In-Reply-To: <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>
Message-ID: <496912688126795164d011f509098175797ac5e9.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 09.11.2022 um 21:04 +0000 schrieb Adam Gundry:
> I'm not sure if we have explicit guidelines regarding conflicts of 
> interest (should we?), but I think I should declare a conflict in this 
> case. The authors of this proposal work for Well-Typed and have proposed 
> and implemented this feature on behalf of a client, which might give the 
> impression of potential bias.
> 
> I am happy to take the advice of the committee on how to handle this 
> situation. While I don't think I need to recuse myself from discussion 
> of the proposal completely, it seems like it would be better for it to 
> be shepherded by someone else?

we tend to have multiple well-tyists or tweagers on the committee, and
so far we mostly worked under the assumption that committee members
manage to do their committee work unencumbered by their jobs. So unless
you, say, personally tasked someone with writing that proposal, or
genuinely (and not just formally) _feel_ conflicted, I’d say don’t
worry. We are all just trying to make GHC better, not govern a country
or something like that :)

That’s my take at least.

Cheers,
Joachim


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


From arnaud.spiwack at tweag.io  Thu Nov 10 09:18:21 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 10 Nov 2022 10:18:21 +0100
Subject: [ghc-steering-committee] Fwd: GHC2023
In-Reply-To: <a5f0f606a97c39e5c09bfbc4d5c887ecf2248f49.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>
Message-ID: <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@mail.gmail.com>

To chime in with data from other communities, in Rust there is a
concept of Edition [1]. They are, likewise, labelled by years.

In your project file (Cargo.toml), you write something like `edition = '2021'`.

This fixes a set of features. It is sold and perceived as a backward
compatibility mechanism. If I set my edition, later Rust compilers
will not break my code. If I want to benefit from new features which
are backward incompatible, I will need to change the edition, and risk
breakage then.

There appears to be a new edition in Rust every 3 years. Which seems
like a reasonable pace to me.


[1]: https://doc.rust-lang.org/edition-guide/index.html


On Tue, 8 Nov 2022 at 12:48, Joachim Breitner <mail at joachim-breitner.de> wrote:
>
> Hi Tom,
>
> thanks for your input! If I may (inadequadly) summarize what I read is
> that we should take into account stability and not just technical
> stability (your code doesn’t have to change as you upgrade your code),
> but also _perceived_ stability (there is GHC2021 and GH2023 and that’s
> confused).
>
> I agree that this is imporant, and worth thinking more about.
>
> In particular: How do other languages treat this? In one of my
> newsfeeds I recently read
>
> > Version 1.65.0 of the Rust language has been released. Improvements
> > include generic associated types, a new let...else statement, and
> > the ability to break from labeled blocks
>
> and also
>
> > Version 3.10.0 of the Python language has been released. There are a
> > lot of significant changes in this release, including the much-
> > discussed structural pattern-matching feature.
>
> so these (popular, non-scary) languages certainly don’t freeze their
> language, and do extend the language repeatedly. Why are they not
> preceived as unstable as Haskell is?
>
> (Here I am really talking about _perceived_ instability, not real
> instability in the sense of _breaking_ changes – the above extensions
> are AFAIK not breaking, and many of our Haskell extensions are not
> breaking.)
>
> It is because we have the concept of a language extension in the first
> place! And, on top of that, now the concept of the current version of
> GHC Haskell. If we didn’t have that in the first place, and no Haskell
> standard, it’d just be the case that GHC-9.2 happens to be the first
> version where you can, say, derive Functor, and that’s it.
>
> My idea of GHC20xx is that it brings us closer to the Rust or Python
> model: Unless you tell GHC you want something else, you get the latest
> stable (in the sense of proven, not in the sense of unchanging) set of
> language features.
>
> And if you want something else (e.g. opt-out of new extensions, or try
> out experimental ones), you have to explicitly ask for it (e.g. pin the
> language version with -XGHC2021, or enable -XFancyTypes). A bit like
> using Rust nightly, just less hassle…
>
> So if you don’t actively do something, you get the same experience as
> in rust or python … and at this point I wonder why this experience is
> perceived as different as in these languages?
>
> (Again, I am focusing here on non-breaking, additive extensions. How to
> handle breaking changes is yet another discussion, of course, and one
> where peeking at Python or Rust is not always showing us the best way
> to do 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 mail at joachim-breitner.de  Thu Nov 10 09:34:11 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 10 Nov 2022 10:34:11 +0100 (GMT+01:00)
Subject: [ghc-steering-committee] Fwd: GHC2023
In-Reply-To: <CAGwnsnmYraDM5sQA9nNCdeja0cd=gz1L6PNOMN038bvzmY=mWw@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>
Message-ID: <4db3ac37-6b85-4427-a4dc-60300b0dfd90@joachim-breitner.de>

Thanks for that!

Do I also have to bump the edition if I want to get my hands on new non-breaking features (e.g. new syntax that simply wasn't legal before)?

10.11.2022 10:19:06 Arnaud Spiwack <arnaud.spiwack at tweag.io>:

> To chime in with data from other communities, in Rust there is a
> concept of Edition [1]. They are, likewise, labelled by years.
> 
> In your project file (Cargo.toml), you write something like `edition = '2021'`.
> 
> This fixes a set of features. It is sold and perceived as a backward
> compatibility mechanism. If I set my edition, later Rust compilers
> will not break my code. If I want to benefit from new features which
> are backward incompatible, I will need to change the edition, and risk
> breakage then.
> 
> There appears to be a new edition in Rust every 3 years. Which seems
> like a reasonable pace to me.
> 
> 
> [1]: https://doc.rust-lang.org/edition-guide/index.html
> 
> 
> On Tue, 8 Nov 2022 at 12:48, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi Tom,
>> 
>> thanks for your input! If I may (inadequadly) summarize what I read is
>> that we should take into account stability and not just technical
>> stability (your code doesn’t have to change as you upgrade your code),
>> but also _perceived_ stability (there is GHC2021 and GH2023 and that’s
>> confused).
>> 
>> I agree that this is imporant, and worth thinking more about.
>> 
>> In particular: How do other languages treat this? In one of my
>> newsfeeds I recently read
>> 
>>> Version 1.65.0 of the Rust language has been released. Improvements
>>> include generic associated types, a new let...else statement, and
>>> the ability to break from labeled blocks
>> 
>> and also
>> 
>>> Version 3.10.0 of the Python language has been released. There are a
>>> lot of significant changes in this release, including the much-
>>> discussed structural pattern-matching feature.
>> 
>> so these (popular, non-scary) languages certainly don’t freeze their
>> language, and do extend the language repeatedly. Why are they not
>> preceived as unstable as Haskell is?
>> 
>> (Here I am really talking about _perceived_ instability, not real
>> instability in the sense of _breaking_ changes – the above extensions
>> are AFAIK not breaking, and many of our Haskell extensions are not
>> breaking.)
>> 
>> It is because we have the concept of a language extension in the first
>> place! And, on top of that, now the concept of the current version of
>> GHC Haskell. If we didn’t have that in the first place, and no Haskell
>> standard, it’d just be the case that GHC-9.2 happens to be the first
>> version where you can, say, derive Functor, and that’s it.
>> 
>> My idea of GHC20xx is that it brings us closer to the Rust or Python
>> model: Unless you tell GHC you want something else, you get the latest
>> stable (in the sense of proven, not in the sense of unchanging) set of
>> language features.
>> 
>> And if you want something else (e.g. opt-out of new extensions, or try
>> out experimental ones), you have to explicitly ask for it (e.g. pin the
>> language version with -XGHC2021, or enable -XFancyTypes). A bit like
>> using Rust nightly, just less hassle…
>> 
>> So if you don’t actively do something, you get the same experience as
>> in rust or python … and at this point I wonder why this experience is
>> perceived as different as in these languages?
>> 
>> (Again, I am focusing here on non-breaking, additive extensions. How to
>> handle breaking changes is yet another discussion, of course, and one
>> where peeking at Python or Rust is not always showing us the best way
>> to do 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 tom-hf at tomellis.org  Sat Nov  5 12:24:12 2022
From: tom-hf at tomellis.org (Tom Ellis)
Date: Sat, 5 Nov 2022 12:24:12 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@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>
Message-ID: <Y2ZV7Odl9wLu4/Pu@cloudinit-builder>

Thanks Simon.

On reflection, I'm not particularly motivated to consult the community
because the concerns I have impinge most strongly on members of the
community who are distant from where a consultation could easily
reach, and on non-but-potential-members of the community who are
getting a false impression from afar.

I will content myself with elaborating on my concerns and then leaving
it to the steering committee to take them into account if they see
fit.  To set the scene, everything I write below is presented from the
point of view of someone who wishes Haskell usage to increase and
believes that we can't increase Haskell usage by appealing to people
who are already comfortable with the way the Haskell ecosystem
currently works: we've already got most of those people.

For the ten years that I have been in the community, Haskell has had a
(false) reputation, to outsiders, as a fragmented language with
multiple mysterious things called "language extensions" each of which
fractures the language in an incompatible way.  "It's impossible to
learn Haskell because there are so many incompatible Haskells" they
say.  It may be hard to believe that this perception exists: as users
of GHC we know that there are very few extensions that introduce any
incompatibility with others; extensions typically just remove
unneccesary restrictions.  But, for those of you who don't spend
far-too-much of your time on discussion fora such as Hacker News and
Reddit, I can guarantee to you that this objection to Haskell comes up
*a lot*.

Haskell also has, to both insiders and outsiders, a (true) reputation
for being an unstable moving target.  "It's impossible to learn or use
Haskell because the language and libraries keep changing", they say.
This one is easier to believe.

GHC2021 is a wonderful way of dealing with all of the first and part
of the second objection!  I can now respond to complaints of language
fragmentation and language instability by simply saying "Turn on
GHC2021 and be happy".  This is great news!

(GHC2021 doesn't deal with instability in libraries of course, but I'm
pleased that there are many people making efforts in that area too.)

I am concerned that GHC2023 would weaken the power of my rejoinder
"Turn on GHC2021 and be happy".  Now I am at risk of the responses
"But why not GHC2023?", "Haskell introduced a new, incompatible
language just two years after standardising on GHC2021", "I just spent
my precious time learning GHC2021, now I have to spend time learning
GHC2023.".  Sure, these responses are based on misunderstandings of
the technical details.  But perceptions really, really matter!  If we
want a large increase in Haskell usage then we have to take
perceptions into account.  We can't substantially increase Haskell
usage any more by appealing just to our techncial excellence.

If we choose to prioritise business-as-usual, that is, the
incorporation of highly technically excellent features on a regular
basis, with no thought to the costs, then the consequence will be
Haskellers-as-usual: people who value that kind of thing in spite of
the costs.  We already have most of those people.  We can't increase
Haskell adoption that way.  If we choose to change tack then we have
the chance of changing the types of people we pick up as new
Haskellers, from among those who would never otherwise have considered
the language.

To put it pithily, Joachim writes in a sibling thread "The point of
the GHC20xx series is to get (proven, useful, uncontroversial) goodies
into the hands of our users".  Are members of the Haskell community,
and indeed non-but-potential-members, screaming out for new "goodies"?
Or are they screaming out for a brief respite from the unforgiving
churn of the Haskell ecosystem, both real and not-real-but-perceived.
My experience of the last ten years tells me it's the latter.

To be clear, I personally am very much looking forward to more highly
technically excellent features, including the exciting ongoing work on
dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
the community that really inspires and excites me! I personally can
tolerate the churn.  But I don't want those things at the *cost* of
continuing to push away potential new users who are currently peering
over the fence, discouraged because they can't tolerate the churn that
they see, real or perceived.

Now, with my stability hat on, looking from the point of view of
process design, it's actually *better* for changes to happen in small
increments, so maybe having GHC20xx every year is actually *better*
than every five years.  I don't wish to advocate for one choice or
another.  Rather I wish to advocate for the point of view that:

  Technical excellence matters.  Stability and the perception of
  stability matter too.

Tom




On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta.
>>
>
> Indeed, we originally said we'd review GHC20xx annually, but I think we
> might want to consult the community to see if that is too often.  There has
> been an interesting thread
> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> Discourse.
>
> The HF Stability Working Group discussed this on Monday, and I think Tom
> Ellis (a member of the SWG) is willing to lead a consultation.  I think
> that would be great -- we have no axe to grind here, and I think we'll be
> delighted to do whatever makes the maximal number of people happy.
>
> Tom (cc'd) will write with more info shortly.  Sound OK?
>
> Simon
>
> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi Committee,
>>
>> when we defined the process for GHC20xx, as written in
>>
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>> we wrote
>>
>>    Likely, the first iteration of this process will be vastly different
>>    from the following ones: The first one is expected to add a large
>>    number of uncontroversial extensions; so the next iteration will
>>    likely only make a smaller, but more controversial change.
>>
>>    Therefore, this proposal does not commit to a fixed cadence.
>>    Instead, 6 months after the first release of a version of GHC that
>>    supports a GHC20xx set, we evaluate the outcome, the process, and
>>    the perceived need of a next release. At that time we will refine
>>    the processes, if needed, and set a cadence.
>>
>> The first version of GHC that supported GHC2021 was 9.2, released in
>> October 2022.
>>
>> Last fall we said that not enough time has passed to do such an
>> evaluation, and we skipped defining GHC2022.
>>
>> Another year has passed, and if we are serious with the idea that
>> GHC20xx is a continuous thing, we should probably start defining
>> GHC2023 – even if it is just a small delta. This e-mail tries to
>> kickstart that process.
>>
>>
>> Last time we did a relative elaborate thing where we voted on
>> essentially _every_ extension. I think that made sense for the first
>> iteration, where we had to winddow down the likely extensions. But now
>> we have a base line (GHC2021), and are asked to find a suitable delta,
>> and I’d go for a nomination-based approach: Committee members can
>> propose adding (or removing, in theory) specific extensions, and then
>> we vote only on those. Does that sound reasonable?
>>
>> Does anyone have any insight from the real world? Has GHC2021 helped
>> our users? And if not, why not?
>>
>> What kind of hard data would you like to see, if any?
>>
>> (I’m a bit wary of spending too much time writing scripts to scrape
>> hackage, for example to see which extensions people tend to enable _in
>> addition_ to GHC2021, only to see that libraries on hackage are
>> understandably slow to use default-language: GHC2021, as that’s not
>> great for backward compat for now. But I am also not sure where to look
>> for good data…)

From mail at joachim-breitner.de  Thu Nov 10 16:14:31 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 10 Nov 2022 17:14:31 +0100
Subject: [ghc-steering-committee] Please review #547: Remove kind
 constraints, Shepherd: Arnaud
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <d240b80644b8ab2bb6a4a50e5c126d74637c4942.camel@joachim-breitner.de>

Dear Committee,

removing kind constraints
has been proposed by Simon PJ and Richard

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

https://github.com/goldfirere/ghc-proposals/blob/no-kind-equalities/proposals/0000-no-kind-equalities.rst

I suggest Arnaud shepherds this proposal.

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


Cheers,
Joachim





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


From lists at richarde.dev  Fri Nov 11 20:37:34 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 11 Nov 2022 20:37:34 +0000
Subject: [ghc-steering-committee] moderation for this list
In-Reply-To: <CAJKmMz__Ms-ZjERPJrxb00-_pTYR52mME+ggvBcPE2hhtp-OYQ@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>
Message-ID: <010f018468697ba6-973ff0ee-9b79-40e1-a080-da9a4fca2b52-000000@us-east-2.amazonses.com>



> On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> (Who, if anyone, is the moderator of the ghc-steering-committee mailing list?)

I am. But perhaps it would be good to add a second moderator as well. Workload is very low -- maybe 1-2 requests per month, 90% of which are spam. I am happy to continue in this role, but there may be delays in delivery.

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

From lists at richarde.dev  Fri Nov 11 20:44:54 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 11 Nov 2022 20:44:54 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <Y2ZV7Odl9wLu4/Pu@cloudinit-builder>
References: <d13c3bc507ed3ff7f8ae2dc2dbde0cdef8874517.camel@joachim-breitner.de>
 <CAJKmMz-j_at002M2DBQu=O9VO9k9MwuMuVkZtts1HWt_tKnu7A@mail.gmail.com>
 <CAJKmMz-8KUqDCWfaiGCSoJ=q_4nYqzKERZ14GE6AS-+8TOn_9g@mail.gmail.com>
 <Y2ZV7Odl9wLu4/Pu@cloudinit-builder>
Message-ID: <010f0184687031c4-ecdf3a95-facd-45b0-a84b-89449d91426d-000000@us-east-2.amazonses.com>

I somehow like 3 years more than 2 here. One reason: the feedback we would like has yet to materialize, because GHC2021 is still not widely available in industry. Industry is slow! (Example: earlier today I had trouble compiling GHC on my work machine because it uses TeXLive 2012, and sphinx has advanced beyond that.)

But I also think there's a terminology problem: extension vs language. Why are some features part of the language and some extensions? It's all because of history. But today's programmers do not care about the history.

There is good news here: GHC2021 is enabled in cabal with `default-language`. And the pragma in Haskell is called {-# LANGUAGE GHC2021 #-}. Hooray!

So I think a better target is releasing a new edition of the Haskell language, dubbed GHC2024, in 2024.

Richard

> On Nov 5, 2022, at 8:24 AM, Tom Ellis <tom-hf at tomellis.org> wrote:
> 
> Thanks Simon.
> 
> On reflection, I'm not particularly motivated to consult the community
> because the concerns I have impinge most strongly on members of the
> community who are distant from where a consultation could easily
> reach, and on non-but-potential-members of the community who are
> getting a false impression from afar.
> 
> I will content myself with elaborating on my concerns and then leaving
> it to the steering committee to take them into account if they see
> fit.  To set the scene, everything I write below is presented from the
> point of view of someone who wishes Haskell usage to increase and
> believes that we can't increase Haskell usage by appealing to people
> who are already comfortable with the way the Haskell ecosystem
> currently works: we've already got most of those people.
> 
> For the ten years that I have been in the community, Haskell has had a
> (false) reputation, to outsiders, as a fragmented language with
> multiple mysterious things called "language extensions" each of which
> fractures the language in an incompatible way.  "It's impossible to
> learn Haskell because there are so many incompatible Haskells" they
> say.  It may be hard to believe that this perception exists: as users
> of GHC we know that there are very few extensions that introduce any
> incompatibility with others; extensions typically just remove
> unneccesary restrictions.  But, for those of you who don't spend
> far-too-much of your time on discussion fora such as Hacker News and
> Reddit, I can guarantee to you that this objection to Haskell comes up
> *a lot*.
> 
> Haskell also has, to both insiders and outsiders, a (true) reputation
> for being an unstable moving target.  "It's impossible to learn or use
> Haskell because the language and libraries keep changing", they say.
> This one is easier to believe.
> 
> GHC2021 is a wonderful way of dealing with all of the first and part
> of the second objection!  I can now respond to complaints of language
> fragmentation and language instability by simply saying "Turn on
> GHC2021 and be happy".  This is great news!
> 
> (GHC2021 doesn't deal with instability in libraries of course, but I'm
> pleased that there are many people making efforts in that area too.)
> 
> I am concerned that GHC2023 would weaken the power of my rejoinder
> "Turn on GHC2021 and be happy".  Now I am at risk of the responses
> "But why not GHC2023?", "Haskell introduced a new, incompatible
> language just two years after standardising on GHC2021", "I just spent
> my precious time learning GHC2021, now I have to spend time learning
> GHC2023.".  Sure, these responses are based on misunderstandings of
> the technical details.  But perceptions really, really matter!  If we
> want a large increase in Haskell usage then we have to take
> perceptions into account.  We can't substantially increase Haskell
> usage any more by appealing just to our techncial excellence.
> 
> If we choose to prioritise business-as-usual, that is, the
> incorporation of highly technically excellent features on a regular
> basis, with no thought to the costs, then the consequence will be
> Haskellers-as-usual: people who value that kind of thing in spite of
> the costs.  We already have most of those people.  We can't increase
> Haskell adoption that way.  If we choose to change tack then we have
> the chance of changing the types of people we pick up as new
> Haskellers, from among those who would never otherwise have considered
> the language.
> 
> To put it pithily, Joachim writes in a sibling thread "The point of
> the GHC20xx series is to get (proven, useful, uncontroversial) goodies
> into the hands of our users".  Are members of the Haskell community,
> and indeed non-but-potential-members, screaming out for new "goodies"?
> Or are they screaming out for a brief respite from the unforgiving
> churn of the Haskell ecosystem, both real and not-real-but-perceived.
> My experience of the last ten years tells me it's the latter.
> 
> To be clear, I personally am very much looking forward to more highly
> technically excellent features, including the exciting ongoing work on
> dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
> the community that really inspires and excites me! I personally can
> tolerate the churn.  But I don't want those things at the *cost* of
> continuing to push away potential new users who are currently peering
> over the fence, discouraged because they can't tolerate the churn that
> they see, real or perceived.
> 
> Now, with my stability hat on, looking from the point of view of
> process design, it's actually *better* for changes to happen in small
> increments, so maybe having GHC20xx every year is actually *better*
> than every five years.  I don't wish to advocate for one choice or
> another.  Rather I wish to advocate for the point of view that:
> 
>  Technical excellence matters.  Stability and the perception of
>  stability matter too.
> 
> Tom
> 
> 
> 
> 
> On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> Another year has passed, and if we are serious with the idea that
>>> GHC20xx is a continuous thing, we should probably start defining
>>> GHC2023 – even if it is just a small delta.
>>> 
>> 
>> Indeed, we originally said we'd review GHC20xx annually, but I think we
>> might want to consult the community to see if that is too often.  There has
>> been an interesting thread
>> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
>> Discourse.
>> 
>> The HF Stability Working Group discussed this on Monday, and I think Tom
>> Ellis (a member of the SWG) is willing to lead a consultation.  I think
>> that would be great -- we have no axe to grind here, and I think we'll be
>> delighted to do whatever makes the maximal number of people happy.
>> 
>> Tom (cc'd) will write with more info shortly.  Sound OK?
>> 
>> Simon
>> 
>> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>> 
>>> Hi Committee,
>>> 
>>> when we defined the process for GHC20xx, as written in
>>> 
>>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
>>> we wrote
>>> 
>>>   Likely, the first iteration of this process will be vastly different
>>>   from the following ones: The first one is expected to add a large
>>>   number of uncontroversial extensions; so the next iteration will
>>>   likely only make a smaller, but more controversial change.
>>> 
>>>   Therefore, this proposal does not commit to a fixed cadence.
>>>   Instead, 6 months after the first release of a version of GHC that
>>>   supports a GHC20xx set, we evaluate the outcome, the process, and
>>>   the perceived need of a next release. At that time we will refine
>>>   the processes, if needed, and set a cadence.
>>> 
>>> The first version of GHC that supported GHC2021 was 9.2, released in
>>> October 2022.
>>> 
>>> Last fall we said that not enough time has passed to do such an
>>> evaluation, and we skipped defining GHC2022.
>>> 
>>> Another year has passed, and if we are serious with the idea that
>>> GHC20xx is a continuous thing, we should probably start defining
>>> GHC2023 – even if it is just a small delta. This e-mail tries to
>>> kickstart that process.
>>> 
>>> 
>>> Last time we did a relative elaborate thing where we voted on
>>> essentially _every_ extension. I think that made sense for the first
>>> iteration, where we had to winddow down the likely extensions. But now
>>> we have a base line (GHC2021), and are asked to find a suitable delta,
>>> and I’d go for a nomination-based approach: Committee members can
>>> propose adding (or removing, in theory) specific extensions, and then
>>> we vote only on those. Does that sound reasonable?
>>> 
>>> Does anyone have any insight from the real world? Has GHC2021 helped
>>> our users? And if not, why not?
>>> 
>>> What kind of hard data would you like to see, if any?
>>> 
>>> (I’m a bit wary of spending too much time writing scripts to scrape
>>> hackage, for example to see which extensions people tend to enable _in
>>> addition_ to GHC2021, only to see that libraries on hackage are
>>> understandably slow to use default-language: GHC2021, as that’s not
>>> great for backward compat for now. But I am also not sure where to look
>>> for good data…)
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From simon.peytonjones at gmail.com  Fri Nov 11 21:36:35 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 11 Nov 2022 21:36:35 +0000
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <010f0184687031c4-ecdf3a95-facd-45b0-a84b-89449d91426d-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>
 <Y2ZV7Odl9wLu4/Pu@cloudinit-builder>
 <010f0184687031c4-ecdf3a95-facd-45b0-a84b-89449d91426d-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz9EnOt3yz1YzxdATkedb9SVy2KjWxehkkwXLooOYQk5gQ@mail.gmail.com>

>
> So I think a better target is releasing a new edition of the Haskell
> language, dubbed GHC2024, in 2024.
>

I'd be happy with that too.

Simon

On Fri, 11 Nov 2022 at 20:45, Richard Eisenberg <lists at richarde.dev> wrote:

> I somehow like 3 years more than 2 here. One reason: the feedback we would
> like has yet to materialize, because GHC2021 is still not widely available
> in industry. Industry is slow! (Example: earlier today I had trouble
> compiling GHC on my work machine because it uses TeXLive 2012, and sphinx
> has advanced beyond that.)
>
> But I also think there's a terminology problem: extension vs language. Why
> are some features part of the language and some extensions? It's all
> because of history. But today's programmers do not care about the history.
>
> There is good news here: GHC2021 is enabled in cabal with
> `default-language`. And the pragma in Haskell is called {-# LANGUAGE
> GHC2021 #-}. Hooray!
>
> So I think a better target is releasing a new edition of the Haskell
> language, dubbed GHC2024, in 2024.
>
> Richard
>
> > On Nov 5, 2022, at 8:24 AM, Tom Ellis <tom-hf at tomellis.org> wrote:
> >
> > Thanks Simon.
> >
> > On reflection, I'm not particularly motivated to consult the community
> > because the concerns I have impinge most strongly on members of the
> > community who are distant from where a consultation could easily
> > reach, and on non-but-potential-members of the community who are
> > getting a false impression from afar.
> >
> > I will content myself with elaborating on my concerns and then leaving
> > it to the steering committee to take them into account if they see
> > fit.  To set the scene, everything I write below is presented from the
> > point of view of someone who wishes Haskell usage to increase and
> > believes that we can't increase Haskell usage by appealing to people
> > who are already comfortable with the way the Haskell ecosystem
> > currently works: we've already got most of those people.
> >
> > For the ten years that I have been in the community, Haskell has had a
> > (false) reputation, to outsiders, as a fragmented language with
> > multiple mysterious things called "language extensions" each of which
> > fractures the language in an incompatible way.  "It's impossible to
> > learn Haskell because there are so many incompatible Haskells" they
> > say.  It may be hard to believe that this perception exists: as users
> > of GHC we know that there are very few extensions that introduce any
> > incompatibility with others; extensions typically just remove
> > unneccesary restrictions.  But, for those of you who don't spend
> > far-too-much of your time on discussion fora such as Hacker News and
> > Reddit, I can guarantee to you that this objection to Haskell comes up
> > *a lot*.
> >
> > Haskell also has, to both insiders and outsiders, a (true) reputation
> > for being an unstable moving target.  "It's impossible to learn or use
> > Haskell because the language and libraries keep changing", they say.
> > This one is easier to believe.
> >
> > GHC2021 is a wonderful way of dealing with all of the first and part
> > of the second objection!  I can now respond to complaints of language
> > fragmentation and language instability by simply saying "Turn on
> > GHC2021 and be happy".  This is great news!
> >
> > (GHC2021 doesn't deal with instability in libraries of course, but I'm
> > pleased that there are many people making efforts in that area too.)
> >
> > I am concerned that GHC2023 would weaken the power of my rejoinder
> > "Turn on GHC2021 and be happy".  Now I am at risk of the responses
> > "But why not GHC2023?", "Haskell introduced a new, incompatible
> > language just two years after standardising on GHC2021", "I just spent
> > my precious time learning GHC2021, now I have to spend time learning
> > GHC2023.".  Sure, these responses are based on misunderstandings of
> > the technical details.  But perceptions really, really matter!  If we
> > want a large increase in Haskell usage then we have to take
> > perceptions into account.  We can't substantially increase Haskell
> > usage any more by appealing just to our techncial excellence.
> >
> > If we choose to prioritise business-as-usual, that is, the
> > incorporation of highly technically excellent features on a regular
> > basis, with no thought to the costs, then the consequence will be
> > Haskellers-as-usual: people who value that kind of thing in spite of
> > the costs.  We already have most of those people.  We can't increase
> > Haskell adoption that way.  If we choose to change tack then we have
> > the chance of changing the types of people we pick up as new
> > Haskellers, from among those who would never otherwise have considered
> > the language.
> >
> > To put it pithily, Joachim writes in a sibling thread "The point of
> > the GHC20xx series is to get (proven, useful, uncontroversial) goodies
> > into the hands of our users".  Are members of the Haskell community,
> > and indeed non-but-potential-members, screaming out for new "goodies"?
> > Or are they screaming out for a brief respite from the unforgiving
> > churn of the Haskell ecosystem, both real and not-real-but-perceived.
> > My experience of the last ten years tells me it's the latter.
> >
> > To be clear, I personally am very much looking forward to more highly
> > technically excellent features, including the exciting ongoing work on
> > dependent types, WASM, GHCJS, and so on.  It's one of the aspects of
> > the community that really inspires and excites me! I personally can
> > tolerate the churn.  But I don't want those things at the *cost* of
> > continuing to push away potential new users who are currently peering
> > over the fence, discouraged because they can't tolerate the churn that
> > they see, real or perceived.
> >
> > Now, with my stability hat on, looking from the point of view of
> > process design, it's actually *better* for changes to happen in small
> > increments, so maybe having GHC20xx every year is actually *better*
> > than every five years.  I don't wish to advocate for one choice or
> > another.  Rather I wish to advocate for the point of view that:
> >
> >  Technical excellence matters.  Stability and the perception of
> >  stability matter too.
> >
> > Tom
> >
> >
> >
> >
> > On Tue, 1 Nov 2022 at 11:43, Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
> >> Another year has passed, and if we are serious with the idea that
> >>> GHC20xx is a continuous thing, we should probably start defining
> >>> GHC2023 – even if it is just a small delta.
> >>>
> >>
> >> Indeed, we originally said we'd review GHC20xx annually, but I think we
> >> might want to consult the community to see if that is too often.  There
> has
> >> been an interesting thread
> >> <https://discourse.haskell.org/t/quo-vadis-ghc2023/5220>on the Haskell
> >> Discourse.
> >>
> >> The HF Stability Working Group discussed this on Monday, and I think Tom
> >> Ellis (a member of the SWG) is willing to lead a consultation.  I think
> >> that would be great -- we have no axe to grind here, and I think we'll
> be
> >> delighted to do whatever makes the maximal number of people happy.
> >>
> >> Tom (cc'd) will write with more info shortly.  Sound OK?
> >>
> >> Simon
> >>
> >> On Mon, 24 Oct 2022 at 20:49, Joachim Breitner <
> mail at joachim-breitner.de>
> >> wrote:
> >>
> >>> Hi Committee,
> >>>
> >>> when we defined the process for GHC20xx, as written in
> >>>
> >>>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst
> >>> we wrote
> >>>
> >>>   Likely, the first iteration of this process will be vastly different
> >>>   from the following ones: The first one is expected to add a large
> >>>   number of uncontroversial extensions; so the next iteration will
> >>>   likely only make a smaller, but more controversial change.
> >>>
> >>>   Therefore, this proposal does not commit to a fixed cadence.
> >>>   Instead, 6 months after the first release of a version of GHC that
> >>>   supports a GHC20xx set, we evaluate the outcome, the process, and
> >>>   the perceived need of a next release. At that time we will refine
> >>>   the processes, if needed, and set a cadence.
> >>>
> >>> The first version of GHC that supported GHC2021 was 9.2, released in
> >>> October 2022.
> >>>
> >>> Last fall we said that not enough time has passed to do such an
> >>> evaluation, and we skipped defining GHC2022.
> >>>
> >>> Another year has passed, and if we are serious with the idea that
> >>> GHC20xx is a continuous thing, we should probably start defining
> >>> GHC2023 – even if it is just a small delta. This e-mail tries to
> >>> kickstart that process.
> >>>
> >>>
> >>> Last time we did a relative elaborate thing where we voted on
> >>> essentially _every_ extension. I think that made sense for the first
> >>> iteration, where we had to winddow down the likely extensions. But now
> >>> we have a base line (GHC2021), and are asked to find a suitable delta,
> >>> and I’d go for a nomination-based approach: Committee members can
> >>> propose adding (or removing, in theory) specific extensions, and then
> >>> we vote only on those. Does that sound reasonable?
> >>>
> >>> Does anyone have any insight from the real world? Has GHC2021 helped
> >>> our users? And if not, why not?
> >>>
> >>> What kind of hard data would you like to see, if any?
> >>>
> >>> (I’m a bit wary of spending too much time writing scripts to scrape
> >>> hackage, for example to see which extensions people tend to enable _in
> >>> addition_ to GHC2021, only to see that libraries on hackage are
> >>> understandably slow to use default-language: GHC2021, as that’s not
> >>> great for backward compat for now. But I am also not sure where to look
> >>> for good data…)
> > _______________________________________________
> > 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/20221111/c04344f0/attachment-0001.html>

From mail at joachim-breitner.de  Sat Nov 12 09:04:21 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sat, 12 Nov 2022 10:04:21 +0100
Subject: [ghc-steering-committee] moderation for this list
In-Reply-To: <010f018468697ba6-973ff0ee-9b79-40e1-a080-da9a4fca2b52-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>
 <010f018468697ba6-973ff0ee-9b79-40e1-a080-da9a4fca2b52-000000@us-east-2.amazonses.com>
Message-ID: <9f23171530bd3263fa61079b7eb89abf186181bc.camel@joachim-breitner.de>

Hi,

feel free to add me. The command line tool listadmin makes dealing with
such small very efficient.

Cheers,
Joachim

Am Freitag, dem 11.11.2022 um 20:37 +0000 schrieb Richard Eisenberg:
> 
> 
> > On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones
> > <simon.peytonjones at gmail.com> wrote:
> > 
> > (Who, if anyone, is the moderator of the ghc-steering-committee
> > mailing list?)
> 
> I am. But perhaps it would be good to add a second moderator as well.
> Workload is very low -- maybe 1-2 requests per month, 90% of which
> are spam. I am happy to continue in this role, but there may be
> delays in delivery.
> 
> Richard
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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


From arnaud.spiwack at tweag.io  Mon Nov 14 10:28:55 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 14 Nov 2022 11:28:55 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
	Recommendation: accept
Message-ID: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>

Dear all,

Our own Richard and Simon PJ are proposing to remove kind constraints from
GHC https://github.com/ghc-proposals/ghc-proposals/pull/547

What are they? Well, exactly. It is a little known feature that you can add
constraints in kinds. Actually, you can only have equality constraints
(e.g. a~Boo => t -> Type (I actually wanted to write Bool, but I decided to
keep the typo in honour of the season)), class constraints are already
forbidden.

The feature is of limited use because you are not allowed to actually use
the constraint when writing instances of such a kind. It's purely a
restriction (much like data type contexts). Richard describes the feature
as having been implemented because it was easy, not because it was
answering a particular need (though it is possible to find applications).

Richard and Simon have a problem with this not-very-useful feature: its
mere existence makes their plan to properly separate Constraints and Types
in Core much harder. So they want to just get rid of it.

Now, it's difficult to estimate how much this feature is actually used. As
we've learnt the hard way with the simplified subsumption proposal. I'd
honestly be surprised if there was actually no usage of kind constraints in
the wild. So there is always a risk. But I think that this is a fairly safe
bet that very few people have actually used this feature. On the other hand
the Constraint/Type separation is long overdue. It seems to me that
removing the feature is the right call. I recommend acceptance.

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

From arnaud.spiwack at tweag.io  Mon Nov 14 10:32:47 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 14 Nov 2022 11:32:47 +0100
Subject: [ghc-steering-committee] Fwd: GHC2023
In-Reply-To: <4db3ac37-6b85-4427-a4dc-60300b0dfd90@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>
Message-ID: <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@mail.gmail.com>

> Do I also have to bump the edition if I want to get my hands on new non-breaking features (e.g. new syntax that simply wasn't legal before)?

Not that I know of.

Rust has something kind of akin to extensions that they call unstable
features. You can turn some of them on if you want to live on the edge
(by adding a flag inside a file, e.g. `#![feature(box_syntax)]`). You
have no guarantee of stability for them, they may even get removed in
the next version of the compiler. (there was a time where unstable
features were, in addition, only available in nightly builds I don't
know if it's still the case).
These unstable features get rolled in the compiler pretty quickly. And
I believe that if they are backward compatible, they can get rolled in
between editions (I'm not super practiced with Rust, so I don't pay a
lot of attention to these details). I don't think that all the features have
to be gated by a feature flag at some point. A strict improvement of the
borrow checker would probably just be part of the next release.

I should say that, anecdotally, editions have been pointed out to me
as a reason why Rust is more stable than Haskell.


/Arnaud

From mail at joachim-breitner.de  Mon Nov 14 11:51:28 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 14 Nov 2022 12:51:28 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
Message-ID: <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>

Hi,

Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud Spiwack:
> I recommend acceptance.

authored by Richard and Simon, and double-checked by Arnaud, I’m happy
to concur.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Wed Nov 16 08:54:11 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Nov 2022 09:54:11 +0100
Subject: [ghc-steering-committee] Please review #529: Template Haskell
 quotes as patterns, Shepherd: Eric
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <9e6975dd140e83bebb91b5f832c91f74040b5695.camel@joachim-breitner.de>

Dear Committee,

Template Haskell quotes as patterns
has been proposed by John Ericson

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

https://github.com/Ericson2314/ghc-proposals/blob/th-quotes-as-patterns/proposals/0529-th-quotes-as-patterns.rst

I suggest Eric shepherds this proposal.

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


Cheers,
Joachim

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


From adam at well-typed.com  Wed Nov 16 16:13:50 2022
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 16 Nov 2022 16:13:50 +0000
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: Adam
In-Reply-To: <496912688126795164d011f509098175797ac5e9.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>
 <496912688126795164d011f509098175797ac5e9.camel@joachim-breitner.de>
Message-ID: <7cbd178e-bcad-9c6a-1dfd-81b4acc6eeff@well-typed.com>

On 09/11/2022 21:33, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, dem 09.11.2022 um 21:04 +0000 schrieb Adam Gundry:
>> I'm not sure if we have explicit guidelines regarding conflicts of
>> interest (should we?), but I think I should declare a conflict in this
>> case. The authors of this proposal work for Well-Typed and have proposed
>> and implemented this feature on behalf of a client, which might give the
>> impression of potential bias.
>>
>> I am happy to take the advice of the committee on how to handle this
>> situation. While I don't think I need to recuse myself from discussion
>> of the proposal completely, it seems like it would be better for it to
>> be shepherded by someone else?
> 
> we tend to have multiple well-tyists or tweagers on the committee, and
> so far we mostly worked under the assumption that committee members
> manage to do their committee work unencumbered by their jobs. So unless
> you, say, personally tasked someone with writing that proposal, or
> genuinely (and not just formally) _feel_ conflicted, I’d say don’t
> worry. We are all just trying to make GHC better, not govern a country
> or something like that :)

I've talked this over with my colleagues, and I think I am sufficiently 
conflicted that I shouldn't shepherd the proposal. In particular, I've 
have had frequent discussions of the work with the authors and our 
client, so it would be difficult for me to make an objective 
recommendation for acceptance or rejection.

More broadly, I do think in general it would be preferable for a 
shepherd not to be from the the same company as or a close collaborator 
of the proposal author(s). I accept that in a small community this may 
not always be desirable as a strict rule, not least because the shepherd 
is "merely" making a recommendation to the committee rather than 
formally deciding the fate of the proposal. But I think it is helpful 
where possible for a couple of reasons:

(a) to avoid giving the impression that by having a representative on 
the committee, companies will have an easier time getting their 
proposals accepted; and

(b) to improve the quality of proposals by having them carefully 
scrutinized by a shepherd with a different background from the authors.

Sorry to be ducking out of this one. I'd be happy to swap shepherding 
duties with someone else if there are any proposals in a suitable state 
for that to make sense?

Cheers,

Adam


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

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


From mail at joachim-breitner.de  Wed Nov 16 19:16:29 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Nov 2022 20:16:29 +0100
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
	Recommendation: accept
Message-ID: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>

Dear all,

Adam has submitted “WARNING pragmas with categories” for committee
consideration:
https://github.com/ghc-proposals/ghc-proposals/pull/541
https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst

I’m shepherding that one myself.

WARNING pragmas can come with categories now:
   {-# WARNING [partial] head "This is a partial function, …" #-}

so that one can sensible group them and allow the user to silence the
warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
like with the built-in warning categories.

No language pragma is required (presumably since we are already in a
GHC-specific pragma).

These custom warnings categories need to be prefixed with `x-` on the
command line to keep them separate from the built-in warnings. This is
a decision where I am inviting the committee to bikeshed:
* Do we really need a separator, or is it ok for library-defined 
  warnings to join a built-in category?
* Should it be used in syntax as well (WARNING [x-partial]) for easier 
  predictability and later extension to other prefixes (see below)?

All these custom warning categories are part of the severity group
-Wdefault (on by default, not errors). I expect we eventually want to
give the programmer control over the severity (off by default, error by
default, part of -Wcompat, etc…), but it’s not immediately clear what
to do here, so we can add it latter (another optional field in the
pragma, a separate pragma, a naming convention like xe-foo, or
something else).
Please complain if you think this needs to be addressed here.

Cheers,
Joachim


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


From mail at joachim-breitner.de  Wed Nov 16 19:19:59 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Nov 2022 20:19:59 +0100
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: Adam
In-Reply-To: <7cbd178e-bcad-9c6a-1dfd-81b4acc6eeff@well-typed.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>
 <496912688126795164d011f509098175797ac5e9.camel@joachim-breitner.de>
 <7cbd178e-bcad-9c6a-1dfd-81b4acc6eeff@well-typed.com>
Message-ID: <43d4c0457d0a1e9f6ea15ba8b0b4ac097b547762.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 16.11.2022 um 16:13 +0000 schrieb Adam Gundry:
> I've talked this over with my colleagues, and I think I am sufficiently 
> conflicted that I shouldn't shepherd the proposal.

sure thing, thanks for being careful here.

> More broadly, I do think in general it would be preferable for a 
> shepherd not to be from the the same company as or a close collaborator 
> of the proposal author(s).

I’ll try to pay attention to that more.


> Sorry to be ducking out of this one. I'd be happy to swap shepherding 
> duties with someone else if there are any proposals in a suitable state 
> for that to make sense?

I suggest you swap with Eric on #529, which I just assigned earlier to
day, so he likely didn’t get started already.

Cheers,
Joachim



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


From mail at joachim-breitner.de  Wed Nov 16 19:21:12 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Nov 2022 20:21:12 +0100
Subject: [ghc-steering-committee] Please review #529: Template Haskell
 quotes as patterns, Shepherd: now Adam
In-Reply-To: <9e6975dd140e83bebb91b5f832c91f74040b5695.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <9e6975dd140e83bebb91b5f832c91f74040b5695.camel@joachim-breitner.de>
Message-ID: <9bc0a6f84861b22375a9c315af129a2b47cd21ca.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 16.11.2022 um 09:54 +0100 schrieb Joachim Breitner:
> Template Haskell quotes as patterns
> has been proposed by John Ericson
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/529
> 
> https://github.com/Ericson2314/ghc-proposals/blob/th-quotes-as-patterns/proposals/0529-th-quotes-as-patterns.rst
> 
> I suggest Eric shepherds this proposal.

JFTR, as discussed in the thread on #540, Adam will shepherd this one,
and I’m re-assigning #540 to Eric. Sorry for the back-and-forth!

Cheers,
Joachim

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


From mail at joachim-breitner.de  Wed Nov 16 19:21:46 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 16 Nov 2022 20:21:46 +0100
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: now Eric
In-Reply-To: <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
Message-ID: <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 08.11.2022 um 13:49 +0100 schrieb Joachim Breitner:
> Dear Committee,
> 
> parallelism semaphores
> have been proposed by Douglas Wilson, Sam Derbyshire, Matthew Pickering
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/540
> 
> https://github.com/sheaf/ghc-proposals/blob/jsem/proposals/0540-jsem.rst
> 
> I suggest Adam shepherds this proposal.

JFTR: I’m reassigning this to Eric (hope that’s ok for you).

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


From eric at seidel.io  Thu Nov 17 01:03:54 2022
From: eric at seidel.io (Eric Seidel)
Date: Wed, 16 Nov 2022 20:03:54 -0500
Subject: [ghc-steering-committee] Please review #540: parallelism
 semaphores, Shepherd: Adam
In-Reply-To: <43d4c0457d0a1e9f6ea15ba8b0b4ac097b547762.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <91f4c05a-0c6a-60ae-8007-d177df4f1ea5@well-typed.com>
 <496912688126795164d011f509098175797ac5e9.camel@joachim-breitner.de>
 <7cbd178e-bcad-9c6a-1dfd-81b4acc6eeff@well-typed.com>
 <43d4c0457d0a1e9f6ea15ba8b0b4ac097b547762.camel@joachim-breitner.de>
Message-ID: <2cb8f6a0-6316-4bcc-84c2-a6007bc343c4@app.fastmail.com>



On Wed, Nov 16, 2022, at 14:19, Joachim Breitner wrote:
> I suggest you swap with Eric on #529, which I just assigned earlier to
> day, so he likely didn’t get started already.

I literally just saw that email, so happy to swap.

From arnaud.spiwack at tweag.io  Thu Nov 17 10:17:00 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 17 Nov 2022 11:17:00 +0100
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
Message-ID: <CAGwnsn=nf7oFMiLucT058fdN689+DYLzA3vPbEgLK1N1z7wKhw@mail.gmail.com>

I'm in favour.

For the bikeshedding question, the mathematician in me believes that using
`WARNING [partial]` is more canonical. Except that there is the
`deprectations` category which is suppressed with `-Wno-deprecations` (the
proposal solves this in saying that `-Wno-deprecations` is actually an
alias for `-Wno-x-deprecations`, why not). Pragmatically, though, the more
I think about it, the more I'm favouring enforcing that the warning author
write `WARNING [x-partial]` (it is also permitted to write `[deprecations]`
without an x, which would avoid introducing `x-deprecations` gratuitously).
The explicitness here, I think, helps. The warning category would _always_
be called `x-partial`. It's easier to process, easier to google. The cost
is tiny.

As to the other question: we probably shouldn't permit warnings to join
other warning categories: they are documented in the user guide, and having
one of these warnings trigger for another reason can be potentially quite
confusing. Not every category anyway. Maybe we will find some that can be
sensibly extended. Forcing `WARNING [x-partial]` allows us to whitelist
categories that can be extended with custom warnings.

I don't think that the other alternatives in the proposal need to be
addressed at this point (if anything, I think they are better addressed
when we have more information on how people actually use these new
categories, instead of just guessing what the pain points will be).

/Arnaud

On Wed, 16 Nov 2022 at 20:16, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear all,
>
> Adam has submitted “WARNING pragmas with categories” for committee
> consideration:
> https://github.com/ghc-proposals/ghc-proposals/pull/541
>
> https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst
>
> I’m shepherding that one myself.
>
> WARNING pragmas can come with categories now:
>    {-# WARNING [partial] head "This is a partial function, …" #-}
>
> so that one can sensible group them and allow the user to silence the
> warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
> like with the built-in warning categories.
>
> No language pragma is required (presumably since we are already in a
> GHC-specific pragma).
>
> These custom warnings categories need to be prefixed with `x-` on the
> command line to keep them separate from the built-in warnings. This is
> a decision where I am inviting the committee to bikeshed:
> * Do we really need a separator, or is it ok for library-defined
>   warnings to join a built-in category?
> * Should it be used in syntax as well (WARNING [x-partial]) for easier
>   predictability and later extension to other prefixes (see below)?
>
> All these custom warning categories are part of the severity group
> -Wdefault (on by default, not errors). I expect we eventually want to
> give the programmer control over the severity (off by default, error by
> default, part of -Wcompat, etc…), but it’s not immediately clear what
> to do here, so we can add it latter (another optional field in the
> pragma, a separate pragma, a naming convention like xe-foo, or
> something else).
> Please complain if you think this needs to be addressed here.
>
> 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/20221117/2b4f52fa/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Nov 17 10:20:29 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 17 Nov 2022 11:20:29 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
Message-ID: <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>

> authored by Richard and Simon, and double-checked by Arnaud, I’m happy
> to concur.

😀

To clarify: the main question is whether we are confident that it won't
break too many users. I don't have divination powers that make my word
particularly trustworthy on this point. Yet, I do feel pretty confident.

On Mon, 14 Nov 2022 at 12:51, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud Spiwack:
> > I recommend acceptance.
>
> authored by Richard and Simon, and double-checked by Arnaud, I’m happy
> to concur.
>
> 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/20221117/40e00a02/attachment.html>

From mail at joachim-breitner.de  Thu Nov 17 19:12:52 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 17 Nov 2022 20:12:52 +0100
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <CAGwnsn=nf7oFMiLucT058fdN689+DYLzA3vPbEgLK1N1z7wKhw@mail.gmail.com>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <CAGwnsn=nf7oFMiLucT058fdN689+DYLzA3vPbEgLK1N1z7wKhw@mail.gmail.com>
Message-ID: <33a1363f4bee2adfbdd4caa8e86e8bb10517ec62.camel@joachim-breitner.de>

Hi,

Am Donnerstag, dem 17.11.2022 um 11:17 +0100 schrieb Arnaud Spiwack:
> For the bikeshedding question, the mathematician in me believes that
> using `WARNING [partial]` is more canonical. Except that there is the
> `deprectations` category which is suppressed with `-Wno-deprecations`
> (the proposal solves this in saying that `-Wno-deprecations` is
> actually an alias for `-Wno-x-deprecations`, why not). Pragmatically,
> though, the more I think about it, the more I'm favouring enforcing
> that the warning author write `WARNING [x-partial]` (it is also
> permitted to write `[deprecations]` without an x, which would avoid
> introducing `x-deprecations` gratuitously). The explicitness here, I
> think, helps. The warning category would _always_ be called `x-
> partial`. It's easier to process, easier to google. The cost is tiny.

thanks for the input. I also have the sense that it will be easier to
understand the feature if users sees x-foo everywhere (source and
command lines), and it allows later extensions.

I’ll turn this into a suggestion on the PR.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Fri Nov 18 08:20:55 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 18 Nov 2022 09:20:55 +0100
Subject: [ghc-steering-committee] Please review #546: Make Symbol a newtype
 over String, Shepherd: Chris
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <7590f16bfc68285b7803ac82ea7e77285a336460.camel@joachim-breitner.de>

Dear Committee,

Make Symbol a newtype over String
has been proposed by Oleg Grenus

https://github.com/ghc-proposals/ghc-proposals/pull/546
https://github.com/phadej/ghc-proposals/blob/symbol-type/proposals/0000-symbol-newtype-string.rst

I suggest Chris Dornan shepherds this proposal.

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


Cheers,
Joachim


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


From arnaud.spiwack at tweag.io  Mon Nov 21 08:32:07 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Mon, 21 Nov 2022 09:32:07 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
 <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
Message-ID: <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>

Not many opined. Unless there is opposition, I'll mark the proposal as
acceptable sometime before the end of the week.

On Thu, 17 Nov 2022 at 11:20, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> > authored by Richard and Simon, and double-checked by Arnaud, I’m happy
> > to concur.
>
> 😀
>
> To clarify: the main question is whether we are confident that it won't
> break too many users. I don't have divination powers that make my word
> particularly trustworthy on this point. Yet, I do feel pretty confident.
>
> On Mon, 14 Nov 2022 at 12:51, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud Spiwack:
>> > I recommend acceptance.
>>
>> authored by Richard and Simon, and double-checked by Arnaud, I’m happy
>> to concur.
>>
>> 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/20221121/08e7ba9c/attachment.html>

From lists at richarde.dev  Mon Nov 21 12:40:10 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 21 Nov 2022 12:40:10 +0000
Subject: [ghc-steering-committee] moderation for this list
In-Reply-To: <9f23171530bd3263fa61079b7eb89abf186181bc.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>
 <010f018468697ba6-973ff0ee-9b79-40e1-a080-da9a4fca2b52-000000@us-east-2.amazonses.com>
 <9f23171530bd3263fa61079b7eb89abf186181bc.camel@joachim-breitner.de>
Message-ID: <010f01849a33ffd8-36dc307f-1b1b-466a-a235-69ffb1d52224-000000@us-east-2.amazonses.com>

Done. Thanks!

> On Nov 12, 2022, at 4:04 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> feel free to add me. The command line tool listadmin makes dealing with
> such small very efficient.
> 
> Cheers,
> Joachim
> 
> Am Freitag, dem 11.11.2022 um 20:37 +0000 schrieb Richard Eisenberg:
>> 
>> 
>>> On Nov 8, 2022, at 4:07 AM, Simon Peyton Jones
>>> <simon.peytonjones at gmail.com> wrote:
>>> 
>>> (Who, if anyone, is the moderator of the ghc-steering-committee
>>> mailing list?)
>> 
>> I am. But perhaps it would be good to add a second moderator as well.
>> Workload is very low -- maybe 1-2 requests per month, 90% of which
>> are spam. I am happy to continue in this role, but there may be
>> delays in delivery.
>> 
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From lists at richarde.dev  Mon Nov 21 12:54:49 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 21 Nov 2022 12:54:49 +0000
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
Message-ID: <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>

I'm strongly in favor of this proposal, and I think that would remain true regardless of the shed colors.

But to share some color preferences: I think the x- should be in the warning pragma, as currently written on GitHub. I also think we will soon want to be able to put the warnings into various bins (e.g. Wcompat, which seems very very useful for library writers for the same reasons it's useful for GHC itself). But there's nothing stopping us from expanding this syntax later, e.g. {-# WARNING [x-furble at compat] ... #-} or some such, and maybe it's better to gain experience before overengineering.

Richard

> On Nov 16, 2022, at 2:16 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear all,
> 
> Adam has submitted “WARNING pragmas with categories” for committee
> consideration:
> https://github.com/ghc-proposals/ghc-proposals/pull/541
> https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst
> 
> I’m shepherding that one myself.
> 
> WARNING pragmas can come with categories now:
>   {-# WARNING [partial] head "This is a partial function, …" #-}
> 
> so that one can sensible group them and allow the user to silence the
> warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
> like with the built-in warning categories.
> 
> No language pragma is required (presumably since we are already in a
> GHC-specific pragma).
> 
> These custom warnings categories need to be prefixed with `x-` on the
> command line to keep them separate from the built-in warnings. This is
> a decision where I am inviting the committee to bikeshed:
> * Do we really need a separator, or is it ok for library-defined 
>  warnings to join a built-in category?
> * Should it be used in syntax as well (WARNING [x-partial]) for easier 
>  predictability and later extension to other prefixes (see below)?
> 
> All these custom warning categories are part of the severity group
> -Wdefault (on by default, not errors). I expect we eventually want to
> give the programmer control over the severity (off by default, error by
> default, part of -Wcompat, etc…), but it’s not immediately clear what
> to do here, so we can add it latter (another optional field in the
> pragma, a separate pragma, a naming convention like xe-foo, or
> something else).
> Please complain if you think this needs to be addressed here.
> 
> 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 simon.peytonjones at gmail.com  Mon Nov 21 13:42:12 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 21 Nov 2022 13:42:12 +0000
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>

>
> But to share some color preferences: I think the x- should be in the
> warning pragma, as currently written on GitHub. I also think we will soon
> want to be able to put the warnings into various bins (e.g. Wcompat, which
> seems very very useful for library writers for the same reasons it's useful
> for GHC itself).
>

I'm still a bit baffled by the "x-" bit.  It just seems like extra noise.

Or is there an (entirely implicit) suggestion that eventually we might want
"y-"  and "z-" prefixes, for some y and z?

Simon

On Mon, 21 Nov 2022 at 12:55, Richard Eisenberg <lists at richarde.dev> wrote:

> I'm strongly in favor of this proposal, and I think that would remain true
> regardless of the shed colors.
>
> But to share some color preferences: I think the x- should be in the
> warning pragma, as currently written on GitHub. I also think we will soon
> want to be able to put the warnings into various bins (e.g. Wcompat, which
> seems very very useful for library writers for the same reasons it's useful
> for GHC itself). But there's nothing stopping us from expanding this syntax
> later, e.g. {-# WARNING [x-furble at compat] ... #-} or some such, and maybe
> it's better to gain experience before overengineering.
>
> Richard
>
> > On Nov 16, 2022, at 2:16 PM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >
> > Dear all,
> >
> > Adam has submitted “WARNING pragmas with categories” for committee
> > consideration:
> > https://github.com/ghc-proposals/ghc-proposals/pull/541
> >
> https://github.com/adamgundry/ghc-proposals/blob/warning-pragmas/proposals/0000-warning-pragmas-with-categories.rst
> >
> > I’m shepherding that one myself.
> >
> > WARNING pragmas can come with categories now:
> >   {-# WARNING [partial] head "This is a partial function, …" #-}
> >
> > so that one can sensible group them and allow the user to silence the
> > warning (-Wno-x-partial) or make them errors (-Werror-x-partial), just
> > like with the built-in warning categories.
> >
> > No language pragma is required (presumably since we are already in a
> > GHC-specific pragma).
> >
> > These custom warnings categories need to be prefixed with `x-` on the
> > command line to keep them separate from the built-in warnings. This is
> > a decision where I am inviting the committee to bikeshed:
> > * Do we really need a separator, or is it ok for library-defined
> >  warnings to join a built-in category?
> > * Should it be used in syntax as well (WARNING [x-partial]) for easier
> >  predictability and later extension to other prefixes (see below)?
> >
> > All these custom warning categories are part of the severity group
> > -Wdefault (on by default, not errors). I expect we eventually want to
> > give the programmer control over the severity (off by default, error by
> > default, part of -Wcompat, etc…), but it’s not immediately clear what
> > to do here, so we can add it latter (another optional field in the
> > pragma, a separate pragma, a naming convention like xe-foo, or
> > something else).
> > Please complain if you think this needs to be addressed here.
> >
> > 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/20221121/5de4cb30/attachment.html>

From mail at joachim-breitner.de  Mon Nov 21 20:31:42 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 21 Nov 2022 21:31:42 +0100
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
 <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>
Message-ID: <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de>

Hi,

Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:
> > But to share some color preferences: I think the x- should be in
> > the warning pragma, as currently written on GitHub. I also think we
> > will soon want to be able to put the warnings into various bins
> > (e.g. Wcompat, which seems very very useful for library writers for
> > the same reasons it's useful for GHC itself). 
> > 
> 
> 
> I'm still a bit baffled by the "x-" bit.  It just seems like extra
> noise.
> 
> Or is there an (entirely implicit) suggestion that eventually we
> might want "y-"  and "z-" prefixes, for some y and z?  


Are you baffled by the x- appearing in the flags (-Wno-x-partial) or
that they also appear in the pragmas as in
{-# WARNING [x-partial] "foobar" #-}?

The motivation for the former is namespacing: If we don't keep custom
warnings apart from those genuinely produced by the compiler, because
else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}.
(Last paragraph of section 2)

There is a suggestion to have other prefixes later maybe, to
distinguish warning categories that should be on by default from those
that should go to -Wextra or -Wall etc. (No entirely implicit, though,
section 6.3).

The motivation for the latter is that some think it’s even more
confusiong to have
  {-# WARNING [partial] "foobar" #-}
but -Wno-x-partial, because now our mental models are confused whether
partial or x-partial is the name of that warning category.


I agree that this x-foo business isn't particular aesthetic.
Alternatives:
 * We could simply allow pragmas to use built-in warning categories. 
   Maybe the library author has a good reason to group their warning
   with -Wwrong-do-bind or -Wdodgy-export
   (but it seems a rather dangerous and confusing direction.)
 * We could not require a prefix, but forbid any built-in warning
   categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).

   Then library code would have to rename their categories if they 
   (accidentially) use a category name that a later GHC version starts
   to use themselves.
 * Library authors don't get to choose category names freely, but 
   instead GHC maintains a list of allowed categories (starting with
   partial, but what else?). This would allow us to document their 
   meaning precisely for consistency, and would also allow us to set 
   their default severity (-Wdefault, -Wall etc.).

Do any of these alternatives sound better to you?


 
Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Mon Nov 21 23:18:08 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 21 Nov 2022 23:18:08 +0000
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
 <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>
 <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de>
Message-ID: <CAJKmMz8hjSRk=SKFC1b=L7TjjBH1=FA-WGyTQO+p2VNoNyNkDQ@mail.gmail.com>

Ah, now I understand.   I think the proposal would be stronger if the
Proposed Change Spec contains something like this

   - The warning category in a WARNING pragma must begin with "x-"; e.g.
   `{-# WARNING [x-partial] head #-}`.  The reason for this is so that, the
   command line options `-Wx-partial` and `-Wno-x-partial` can readily be
   distinguished from the existing large number of built-in warning
   categories, such as `-Wtabs`, `-Wdodgy-import`, `-Winaccessible-code` etc.
   See the user manual section
   <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html?highlight=warning#warnings-and-sanity-checking>for
   a complete list.

Doubtless this is said already, but I did not absorb it.

An alternative you don't describe is to use a different -W flag to turn on
and off these user-specified warnings.  E.g. `-Wext:partial`,
`-Wext:no-partial`.  We don't think of this as a category sometimes called
`partial` and sometimes called `ext:partial`.  Rather we think of two flags
`-W` and `-Wext`.    I know this is equivalent to what the proposal said
originally; now I understand it better I can see the original thinking.

I don't feel strongly; but once decided, it needs clear exposition.

Simon

On Mon, 21 Nov 2022 at 20:32, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:
> > > But to share some color preferences: I think the x- should be in
> > > the warning pragma, as currently written on GitHub. I also think we
> > > will soon want to be able to put the warnings into various bins
> > > (e.g. Wcompat, which seems very very useful for library writers for
> > > the same reasons it's useful for GHC itself).
> > >
> >
> >
> > I'm still a bit baffled by the "x-" bit.  It just seems like extra
> > noise.
> >
> > Or is there an (entirely implicit) suggestion that eventually we
> > might want "y-"  and "z-" prefixes, for some y and z?
>
>
> Are you baffled by the x- appearing in the flags (-Wno-x-partial) or
> that they also appear in the pragmas as in
> {-# WARNING [x-partial] "foobar" #-}?
>
> The motivation for the former is namespacing: If we don't keep custom
> warnings apart from those genuinely produced by the compiler, because
> else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}.
> (Last paragraph of section 2)
>
> There is a suggestion to have other prefixes later maybe, to
> distinguish warning categories that should be on by default from those
> that should go to -Wextra or -Wall etc. (No entirely implicit, though,
> section 6.3).
>
> The motivation for the latter is that some think it’s even more
> confusiong to have
>   {-# WARNING [partial] "foobar" #-}
> but -Wno-x-partial, because now our mental models are confused whether
> partial or x-partial is the name of that warning category.
>
>
> I agree that this x-foo business isn't particular aesthetic.
> Alternatives:
>  * We could simply allow pragmas to use built-in warning categories.
>    Maybe the library author has a good reason to group their warning
>    with -Wwrong-do-bind or -Wdodgy-export
>    (but it seems a rather dangerous and confusing direction.)
>  * We could not require a prefix, but forbid any built-in warning
>    categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).
>
>    Then library code would have to rename their categories if they
>    (accidentially) use a category name that a later GHC version starts
>    to use themselves.
>  * Library authors don't get to choose category names freely, but
>    instead GHC maintains a list of allowed categories (starting with
>    partial, but what else?). This would allow us to document their
>    meaning precisely for consistency, and would also allow us to set
>    their default severity (-Wdefault, -Wall etc.).
>
> Do any of these alternatives sound better to you?
>
>
>
> 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/20221121/292e0209/attachment.html>

From adam at well-typed.com  Tue Nov 22 09:31:41 2022
From: adam at well-typed.com (Adam Gundry)
Date: Tue, 22 Nov 2022 09:31:41 +0000
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
 <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
 <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>
Message-ID: <791be9fa-7411-eb4e-3748-1c4ac4d1385d@well-typed.com>

I'm not extremely worried about removing equality constraints in kinds 
themselves, but I am slightly worried that this proposal will 
unexpectedly prevent (existing) uses of GADTs with DataKinds. If I 
understand correctly, this version of MkT will be usable in types:

   data T a where
     MkT :: Bool -> T Bool

but this will not (even though it could be rewritten to the former):

   data T a where
     MkT :: a ~ Bool => Bool -> T a

Moreover, this MkT not be usable in types at all:

   type family F a
   data T a where
     MkT :: F a ~ Bool => Bool -> T a

I suppose we can live with this in exchange for the gain in simplicity, 
especially as there seems to be agreement that maintaining the feature 
is simply too costly. But I would not be all that surprised if some 
users' code breaks as a result.

Cheers,

Adam


On 21/11/2022 08:32, Arnaud Spiwack wrote:
> Not many opined. Unless there is opposition, I'll mark the proposal as 
> acceptable sometime before the end of the week.
> 
> On Thu, 17 Nov 2022 at 11:20, Arnaud Spiwack <arnaud.spiwack at tweag.io 
> <mailto:arnaud.spiwack at tweag.io>> wrote:
> 
>      > authored by Richard and Simon, and double-checked by Arnaud, I’m
>     happy
>      > to concur.
> 
>     😀
> 
>     To clarify: the main question is whether we are confident that it
>     won't break too many users. I don't have divination powers that make
>     my word particularly trustworthy on this point. Yet, I do feel
>     pretty confident.
> 
>     On Mon, 14 Nov 2022 at 12:51, Joachim Breitner
>     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> 
>         Hi,
> 
>         Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud Spiwack:
>          > I recommend acceptance.
> 
>         authored by Richard and Simon, and double-checked by Arnaud, I’m
>         happy
>         to concur.
> 
>         Cheers,
>         Joachim
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

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


From mail at joachim-breitner.de  Wed Nov 23 16:51:54 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 23 Nov 2022 17:51:54 +0100
Subject: [ghc-steering-committee] GHC2023
In-Reply-To: <CAGwnsnmHaHBpTxoh4_UsL9fjkj+ZZPDc2SWWjZ2Yxz7PB9GOGw@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>
Message-ID: <202335729168235d1bcd605a1c702311aa0e2889.camel@joachim-breitner.de>

Hi,

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.

Cheers,
Joachim


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


From arnaud.spiwack at tweag.io  Thu Nov 24 09:22:39 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Thu, 24 Nov 2022 10:22:39 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <791be9fa-7411-eb4e-3748-1c4ac4d1385d@well-typed.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
 <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
 <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>
 <791be9fa-7411-eb4e-3748-1c4ac4d1385d@well-typed.com>
Message-ID: <CAGwnsnkapPMd9V2KQGZccJCi7SWc306zT-STBVuAQktxG8AmuA@mail.gmail.com>

Adam makes an excellent point. GADTs defined with explicit equality
constraints and then promoted is likely to be the main reason for breakage.
If only because programmers doing that would probably not even really be
aware that they are using constraints in kinds. On the other hand, I don't
think that it's super common to defined a GADT that way, so the number of
promoted GADTs will be small.

Adam, do you nevertheless support acceptance? Does anybody else have an
opinion? I intend to mark the proposal as accepted tomorrow unless there is
clear opposition.

On Tue, 22 Nov 2022 at 10:32, Adam Gundry <adam at well-typed.com> wrote:

> I'm not extremely worried about removing equality constraints in kinds
> themselves, but I am slightly worried that this proposal will
> unexpectedly prevent (existing) uses of GADTs with DataKinds. If I
> understand correctly, this version of MkT will be usable in types:
>
>    data T a where
>      MkT :: Bool -> T Bool
>
> but this will not (even though it could be rewritten to the former):
>
>    data T a where
>      MkT :: a ~ Bool => Bool -> T a
>
> Moreover, this MkT not be usable in types at all:
>
>    type family F a
>    data T a where
>      MkT :: F a ~ Bool => Bool -> T a
>
> I suppose we can live with this in exchange for the gain in simplicity,
> especially as there seems to be agreement that maintaining the feature
> is simply too costly. But I would not be all that surprised if some
> users' code breaks as a result.
>
> Cheers,
>
> Adam
>
>
> On 21/11/2022 08:32, Arnaud Spiwack wrote:
> > Not many opined. Unless there is opposition, I'll mark the proposal as
> > acceptable sometime before the end of the week.
> >
> > On Thu, 17 Nov 2022 at 11:20, Arnaud Spiwack <arnaud.spiwack at tweag.io
> > <mailto:arnaud.spiwack at tweag.io>> wrote:
> >
> >      > authored by Richard and Simon, and double-checked by Arnaud, I’m
> >     happy
> >      > to concur.
> >
> >     😀
> >
> >     To clarify: the main question is whether we are confident that it
> >     won't break too many users. I don't have divination powers that make
> >     my word particularly trustworthy on this point. Yet, I do feel
> >     pretty confident.
> >
> >     On Mon, 14 Nov 2022 at 12:51, Joachim Breitner
> >     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> >
> >         Hi,
> >
> >         Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud Spiwack:
> >          > I recommend acceptance.
> >
> >         authored by Richard and Simon, and double-checked by Arnaud, I’m
> >         happy
> >         to concur.
> >
> >         Cheers,
> >         Joachim
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> --
> 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/20221124/87666903/attachment.html>

From adam at well-typed.com  Fri Nov 25 08:57:41 2022
From: adam at well-typed.com (Adam Gundry)
Date: Fri, 25 Nov 2022 08:57:41 +0000
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <CAGwnsnkapPMd9V2KQGZccJCi7SWc306zT-STBVuAQktxG8AmuA@mail.gmail.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
 <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
 <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>
 <791be9fa-7411-eb4e-3748-1c4ac4d1385d@well-typed.com>
 <CAGwnsnkapPMd9V2KQGZccJCi7SWc306zT-STBVuAQktxG8AmuA@mail.gmail.com>
Message-ID: <2826abe1-c176-cab5-56c6-a17ff3de7ecb@well-typed.com>

On 24/11/2022 09:22, Arnaud Spiwack wrote:
> Adam makes an excellent point. GADTs defined with explicit equality 
> constraints and then promoted is likely to be the main reason for 
> breakage. If only because programmers doing that would probably not even 
> really be aware that they are using constraints in kinds. On the other 
> hand, I don't think that it's super common to defined a GADT that way, 
> so the number of promoted GADTs will be small.
> 
> Adam, do you nevertheless support acceptance? Does anybody else have an 
> opinion? I intend to mark the proposal as accepted tomorrow unless there 
> is clear opposition.

Yes, I'm okay with acceptance. As you say, this is not the most common 
way to define GADTs, and given that (a) any class context prevents use 
in types, and (b) dependent pattern matching on GADTs doesn't work in 
type families anyway, it seems best to take the simple position that any 
context at all prevents use of a data constructor in a type.

Cheers,

Adam


> On Tue, 22 Nov 2022 at 10:32, Adam Gundry <adam at well-typed.com 
> <mailto:adam at well-typed.com>> wrote:
> 
>     I'm not extremely worried about removing equality constraints in kinds
>     themselves, but I am slightly worried that this proposal will
>     unexpectedly prevent (existing) uses of GADTs with DataKinds. If I
>     understand correctly, this version of MkT will be usable in types:
> 
>         data T a where
>           MkT :: Bool -> T Bool
> 
>     but this will not (even though it could be rewritten to the former):
> 
>         data T a where
>           MkT :: a ~ Bool => Bool -> T a
> 
>     Moreover, this MkT not be usable in types at all:
> 
>         type family F a
>         data T a where
>           MkT :: F a ~ Bool => Bool -> T a
> 
>     I suppose we can live with this in exchange for the gain in simplicity,
>     especially as there seems to be agreement that maintaining the feature
>     is simply too costly. But I would not be all that surprised if some
>     users' code breaks as a result.
> 
>     Cheers,
> 
>     Adam
> 
> 
>     On 21/11/2022 08:32, Arnaud Spiwack wrote:
>      > Not many opined. Unless there is opposition, I'll mark the
>     proposal as
>      > acceptable sometime before the end of the week.
>      >
>      > On Thu, 17 Nov 2022 at 11:20, Arnaud Spiwack
>     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>
>      > <mailto:arnaud.spiwack at tweag.io
>     <mailto:arnaud.spiwack at tweag.io>>> wrote:
>      >
>      >      > authored by Richard and Simon, and double-checked by
>     Arnaud, I’m
>      >     happy
>      >      > to concur.
>      >
>      >     😀
>      >
>      >     To clarify: the main question is whether we are confident that it
>      >     won't break too many users. I don't have divination powers
>     that make
>      >     my word particularly trustworthy on this point. Yet, I do feel
>      >     pretty confident.
>      >
>      >     On Mon, 14 Nov 2022 at 12:51, Joachim Breitner
>      >     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>     <mailto:mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>>
>     wrote:
>      >
>      >         Hi,
>      >
>      >         Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud
>     Spiwack:
>      >          > I recommend acceptance.
>      >
>      >         authored by Richard and Simon, and double-checked by
>     Arnaud, I’m
>      >         happy
>      >         to concur.
>      >
>      >         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 Nov 25 15:47:32 2022
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 25 Nov 2022 16:47:32 +0100
Subject: [ghc-steering-committee] #547: Remove kind constraints,
 Recommendation: accept
In-Reply-To: <2826abe1-c176-cab5-56c6-a17ff3de7ecb@well-typed.com>
References: <CAGwnsnnVMgM-cnx=R76OSqiPJH+=Ti9Npe6S8jznJp3RN3wihA@mail.gmail.com>
 <f235dd9d0cffceea6e42bd59781fcb9416a9370f.camel@joachim-breitner.de>
 <CAGwnsnmYAUv9sJh=TchH8dbWDLhqA3v-uTP4xjnOV2FYUT1xHA@mail.gmail.com>
 <CAGwnsnnk+sAK7FR3LKAnv_Wwms8frcL0pWWRkoyoM-F0xfTOzQ@mail.gmail.com>
 <791be9fa-7411-eb4e-3748-1c4ac4d1385d@well-typed.com>
 <CAGwnsnkapPMd9V2KQGZccJCi7SWc306zT-STBVuAQktxG8AmuA@mail.gmail.com>
 <2826abe1-c176-cab5-56c6-a17ff3de7ecb@well-typed.com>
Message-ID: <CAGwnsn=-BPqEcecRXhb3HmMgdnnDPHKm7K+Kv7n-USv8dMyGtA@mail.gmail.com>

Ok, then. I think that we can mark this proposal as accepted.

On Fri, 25 Nov 2022 at 09:58, Adam Gundry <adam at well-typed.com> wrote:

> On 24/11/2022 09:22, Arnaud Spiwack wrote:
> > Adam makes an excellent point. GADTs defined with explicit equality
> > constraints and then promoted is likely to be the main reason for
> > breakage. If only because programmers doing that would probably not even
> > really be aware that they are using constraints in kinds. On the other
> > hand, I don't think that it's super common to defined a GADT that way,
> > so the number of promoted GADTs will be small.
> >
> > Adam, do you nevertheless support acceptance? Does anybody else have an
> > opinion? I intend to mark the proposal as accepted tomorrow unless there
> > is clear opposition.
>
> Yes, I'm okay with acceptance. As you say, this is not the most common
> way to define GADTs, and given that (a) any class context prevents use
> in types, and (b) dependent pattern matching on GADTs doesn't work in
> type families anyway, it seems best to take the simple position that any
> context at all prevents use of a data constructor in a type.
>
> Cheers,
>
> Adam
>
>
> > On Tue, 22 Nov 2022 at 10:32, Adam Gundry <adam at well-typed.com
> > <mailto:adam at well-typed.com>> wrote:
> >
> >     I'm not extremely worried about removing equality constraints in
> kinds
> >     themselves, but I am slightly worried that this proposal will
> >     unexpectedly prevent (existing) uses of GADTs with DataKinds. If I
> >     understand correctly, this version of MkT will be usable in types:
> >
> >         data T a where
> >           MkT :: Bool -> T Bool
> >
> >     but this will not (even though it could be rewritten to the former):
> >
> >         data T a where
> >           MkT :: a ~ Bool => Bool -> T a
> >
> >     Moreover, this MkT not be usable in types at all:
> >
> >         type family F a
> >         data T a where
> >           MkT :: F a ~ Bool => Bool -> T a
> >
> >     I suppose we can live with this in exchange for the gain in
> simplicity,
> >     especially as there seems to be agreement that maintaining the
> feature
> >     is simply too costly. But I would not be all that surprised if some
> >     users' code breaks as a result.
> >
> >     Cheers,
> >
> >     Adam
> >
> >
> >     On 21/11/2022 08:32, Arnaud Spiwack wrote:
> >      > Not many opined. Unless there is opposition, I'll mark the
> >     proposal as
> >      > acceptable sometime before the end of the week.
> >      >
> >      > On Thu, 17 Nov 2022 at 11:20, Arnaud Spiwack
> >     <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>
> >      > <mailto:arnaud.spiwack at tweag.io
> >     <mailto:arnaud.spiwack at tweag.io>>> wrote:
> >      >
> >      >      > authored by Richard and Simon, and double-checked by
> >     Arnaud, I’m
> >      >     happy
> >      >      > to concur.
> >      >
> >      >     😀
> >      >
> >      >     To clarify: the main question is whether we are confident
> that it
> >      >     won't break too many users. I don't have divination powers
> >     that make
> >      >     my word particularly trustworthy on this point. Yet, I do feel
> >      >     pretty confident.
> >      >
> >      >     On Mon, 14 Nov 2022 at 12:51, Joachim Breitner
> >      >     <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> >     <mailto:mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>>>
> >     wrote:
> >      >
> >      >         Hi,
> >      >
> >      >         Am Montag, dem 14.11.2022 um 11:28 +0100 schrieb Arnaud
> >     Spiwack:
> >      >          > I recommend acceptance.
> >      >
> >      >         authored by Richard and Simon, and double-checked by
> >     Arnaud, I’m
> >      >         happy
> >      >         to concur.
> >      >
> >      >         Cheers,
> >      >         Joachim
>
> --
> Adam Gundry, Haskell Consultant
> Well-Typed LLP, https://www.well-typed.com/
>
> Registered in England & Wales, OC335890
> 27 Old Gloucester Street, London WC1N 3AX, England
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221125/7d7ba9c1/attachment.html>

From mail at joachim-breitner.de  Sun Nov 27 10:25:40 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 27 Nov 2022 11:25:40 +0100
Subject: [ghc-steering-committee] Please review #556: fix signature
 scopingin #448, Shepherd: Richard
In-Reply-To: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
Message-ID: <b14cae28a0b3f193554d059f1cc7ab7d65c32df2.camel@joachim-breitner.de>

Dear Committee,

Vlad proposes to fix signature scoping in the
Modern Scoped Type Variables proposal (#448).

https://github.com/ghc-proposals/ghc-proposals/pull/556
(This is a fix to an existing proposal, so no separate proposal file).

I suggest Richard, as the original author of #448, to shepherd this proposal.

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


Cheers,
Joachim


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


From mail at joachim-breitner.de  Sun Nov 27 10:39:51 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 27 Nov 2022 11:39:51 +0100
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
Message-ID: <f26e44b69b595dedd1a3bc7fa37083c1999765c0.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 16.11.2022 um 20:16 +0100 schrieb Joachim Breitner:
> Adam has submitted “WARNING pragmas with categories” for committee

I got minor tweaks ([x-partial] in the pragma, thanks Arnaud) and
proposal text improvements  (thanks Simon), and strong support, but no
complaints.

I’ll merge within a week if stays this way.

Cheers,
Joachim


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


From mail at joachim-breitner.de  Sun Nov 27 11:10:23 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 27 Nov 2022 12:10:23 +0100
Subject: [ghc-steering-committee]  GHC Steering Committee Status
Message-ID: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>

Dear Committee,

let’s do another ~bi~trimonthly status update. There was an uptick in
submissions recently, and our backlog is on the large side; it looks
like almost everyone 

So what has happened since the last one?

 * Baldur has stepped down, Arnaud has renewed their term and Adam Gundy joined.
   Thanks all!

 * I started a discussion on whether we should have GHC2021. I sense some hesitation,
   but not enough yet to discourage me, so I stated to draft a proposal at
   https://github.com/ghc-proposals/ghc-proposals/pull/559
   and you are all invited to nominate those extensions you’d like to be on by
   default in the future.

 * we were asked to review these proposals:
  
   #532: Clean up implicit binding, Shepherd: Arnaud
   #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
   #526: Applicative Comprehensions, Shepherd: Simon M
   #540: parallelism semaphores, Shepherd: Eric 
   #547: Remove kind constraints, Shepherd: Arnaud
   #529: Template Haskell quotes as patterns, Shepherd: Adam
   #451: WARNING pragma with category, Shepherd: Joachim
   #546: Make Symbol a newtype over String, Shepherd: Chris
   #556: fix signature scoping #448, Shepherd: Richard

 * we have a recommendation from the shepherd about:

   #522: Or patterns. Recommendation: accept
   #516: Introduce `-Wincomplete-record-selectors`, Rec: accept
   #270: Support pun-free code. Rec: accept
   #500: Add implicit import proposal, rec: reject
   #547: Remove kind constraints, Recommendation: accept
   #451: WARNING pragma with category, rec: accept

 * we have sent the following proposals back to revision

   (none)

 * we decided about the following proposals

   #517: Require implementors before proposal submission (reject)
   #516: Introduce `-Wincomplete-record-selectors (accept)
   #547: Remove kind constraints, Recommendation: accept
   #500: Add implicit import proposal (reject)

We currently have to act on the following 12 proposals, double
the number as last time!

## Waiting for committee decision

#270: Support pun-free code, Shepherd: Chris
      2022-01-01: Assigned to Chris
      2022-08-24: Chris suggests acceptance
      2022-09-08: Last message
      Chris, can you conclude this discussion?

#515 Relaxing HasField constraints
      2022-08-01: Assigned to Tom
      2022-08-10: Tom suggests acceptance
      Still no comments. Tom, please drive this discussion!

#522: Or Patterns
      2022-08-08: Assigned to Richard
      2022-08-19: Richard recommends acceptance
      2022-10-18: Last message
      Richard, is this discussion converging?

#451: WARNING pragma with category, Shepherd: Joachim
      Acceptance seems imminent 

## Waiting for shepherd recommendation

#330: Decorate exceptions with backtrace information, Shepherd: Vlad
      2022-06-25: Assignd to Vlad
      This seems to have fallen through the cracks.
      Vlad, please make a recommendation!

#512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
      2022-09-03: Assignd to Baldur
      2022-10-02: Reassignd to Vlad

#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

#532: Clean up implicit binding, Shepherd: Arnaud   
      2022-08-23: Assigned to Arnaud
      Sent back for revision
      2022-11-27: Resubmitted

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

#546: Make Symbol a newtype over String, Shepherd: Chris
      2022-11-18: Assigned to Chris

#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  Mon Nov 28 10:34:16 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 28 Nov 2022 10:34:16 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
References: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
Message-ID: <CAJKmMz83BTGvzgBJ14cMdc-darcnArxzwv32RAt2+7xuT8cOeA@mail.gmail.com>

Thank you Joachim for keeping us in touch.

*Everyone*: it's important that we respond to authors in a timely manner
(days or weeks, definitely not months), otherwise the process begins to
feel tiresome and bureaucratic -- and it's disrespectful to our proposal
authors.

Shepherds, your active intervention is critical.  Group responsibilities
fall down the cracks, which is why we need a shepherd for each proposal to
make sure it keeps moving.  If you don't feel able to serve, it's better to
step down.  But it's not very onerous and it's probably just a question of
getting this small task onto your front burner!

So, if you are a shepherd in the list below, please could you find time to
move it along?   It's ok to bounce it back to the author for specified
revisions and resubmission.  Not so OK for it simply to languish.

Thank you!

Simon


On Sun, 27 Nov 2022 at 11:10, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> let’s do another ~bi~trimonthly status update. There was an uptick in
> submissions recently, and our backlog is on the large side; it looks
> like almost everyone
>
> So what has happened since the last one?
>
>  * Baldur has stepped down, Arnaud has renewed their term and Adam Gundy
> joined.
>    Thanks all!
>
>  * I started a discussion on whether we should have GHC2021. I sense some
> hesitation,
>    but not enough yet to discourage me, so I stated to draft a proposal at
>    https://github.com/ghc-proposals/ghc-proposals/pull/559
>    and you are all invited to nominate those extensions you’d like to be
> on by
>    default in the future.
>
>  * we were asked to review these proposals:
>
>    #532: Clean up implicit binding, Shepherd: Arnaud
>    #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>    #526: Applicative Comprehensions, Shepherd: Simon M
>    #540: parallelism semaphores, Shepherd: Eric
>    #547: Remove kind constraints, Shepherd: Arnaud
>    #529: Template Haskell quotes as patterns, Shepherd: Adam
>    #451: WARNING pragma with category, Shepherd: Joachim
>    #546: Make Symbol a newtype over String, Shepherd: Chris
>    #556: fix signature scoping #448, Shepherd: Richard
>
>  * we have a recommendation from the shepherd about:
>
>    #522: Or patterns. Recommendation: accept
>    #516: Introduce `-Wincomplete-record-selectors`, Rec: accept
>    #270: Support pun-free code. Rec: accept
>    #500: Add implicit import proposal, rec: reject
>    #547: Remove kind constraints, Recommendation: accept
>    #451: WARNING pragma with category, rec: accept
>
>  * we have sent the following proposals back to revision
>
>    (none)
>
>  * we decided about the following proposals
>
>    #517: Require implementors before proposal submission (reject)
>    #516: Introduce `-Wincomplete-record-selectors (accept)
>    #547: Remove kind constraints, Recommendation: accept
>    #500: Add implicit import proposal (reject)
>
> We currently have to act on the following 12 proposals, double
> the number as last time!
>
> ## Waiting for committee decision
>
> #270: Support pun-free code, Shepherd: Chris
>       2022-01-01: Assigned to Chris
>       2022-08-24: Chris suggests acceptance
>       2022-09-08: Last message
>       Chris, can you conclude this discussion?
>
> #515 Relaxing HasField constraints
>       2022-08-01: Assigned to Tom
>       2022-08-10: Tom suggests acceptance
>       Still no comments. Tom, please drive this discussion!
>
> #522: Or Patterns
>       2022-08-08: Assigned to Richard
>       2022-08-19: Richard recommends acceptance
>       2022-10-18: Last message
>       Richard, is this discussion converging?
>
> #451: WARNING pragma with category, Shepherd: Joachim
>       Acceptance seems imminent
>
> ## Waiting for shepherd recommendation
>
> #330: Decorate exceptions with backtrace information, Shepherd: Vlad
>       2022-06-25: Assignd to Vlad
>       This seems to have fallen through the cracks.
>       Vlad, please make a recommendation!
>
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>       2022-09-03: Assignd to Baldur
>       2022-10-02: Reassignd to Vlad
>
> #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
>
> #532: Clean up implicit binding, Shepherd: Arnaud
>       2022-08-23: Assigned to Arnaud
>       Sent back for revision
>       2022-11-27: Resubmitted
>
> #540: parallelism semaphores, Shepherd: Eric
>       2022-11-08: Assigned to Adam
>       2022-11-17: Re-assigned to Eric
>
> #546: Make Symbol a newtype over String, Shepherd: Chris
>       2022-11-18: Assigned to Chris
>
> #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/20221128/00653544/attachment.html>

From chris at chrisdornan.com  Mon Nov 28 16:50:39 2022
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 28 Nov 2022 16:50:39 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
References: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
Message-ID: <5B8138D5-D23E-4060-8DA4-83E66E83FFCE@chrisdornan.com>

I have responded on #270 <https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-1329382532> (Support pun-free code) asking some wording be added to the preable to make it clear that the constructions that it is warning about are essentially a matter of style and we are not making any judgements on what is good or valid style, but merely providing tools to help those that wish to manage the use of puns in code.

This is not to prejudge the wider question of whether we should be trying to move away from puns.

Chris

> On 27 Nov 2022, at 11:10, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Dear Committee,
> 
> let’s do another ~bi~trimonthly status update. There was an uptick in
> submissions recently, and our backlog is on the large side; it looks
> like almost everyone 
> 
> So what has happened since the last one?
> 
> * Baldur has stepped down, Arnaud has renewed their term and Adam Gundy joined.
>   Thanks all!
> 
> * I started a discussion on whether we should have GHC2021. I sense some hesitation,
>   but not enough yet to discourage me, so I stated to draft a proposal at
>   https://github.com/ghc-proposals/ghc-proposals/pull/559
>   and you are all invited to nominate those extensions you’d like to be on by
>   default in the future.
> 
> * we were asked to review these proposals:
> 
>   #532: Clean up implicit binding, Shepherd: Arnaud
>   #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>   #526: Applicative Comprehensions, Shepherd: Simon M
>   #540: parallelism semaphores, Shepherd: Eric 
>   #547: Remove kind constraints, Shepherd: Arnaud
>   #529: Template Haskell quotes as patterns, Shepherd: Adam
>   #451: WARNING pragma with category, Shepherd: Joachim
>   #546: Make Symbol a newtype over String, Shepherd: Chris
>   #556: fix signature scoping #448, Shepherd: Richard
> 
> * we have a recommendation from the shepherd about:
> 
>   #522: Or patterns. Recommendation: accept
>   #516: Introduce `-Wincomplete-record-selectors`, Rec: accept
>   #270: Support pun-free code. Rec: accept
>   #500: Add implicit import proposal, rec: reject
>   #547: Remove kind constraints, Recommendation: accept
>   #451: WARNING pragma with category, rec: accept
> 
> * we have sent the following proposals back to revision
> 
>   (none)
> 
> * we decided about the following proposals
> 
>   #517: Require implementors before proposal submission (reject)
>   #516: Introduce `-Wincomplete-record-selectors (accept)
>   #547: Remove kind constraints, Recommendation: accept
>   #500: Add implicit import proposal (reject)
> 
> We currently have to act on the following 12 proposals, double
> the number as last time!
> 
> ## Waiting for committee decision
> 
> #270: Support pun-free code, Shepherd: Chris
>      2022-01-01: Assigned to Chris
>      2022-08-24: Chris suggests acceptance
>      2022-09-08: Last message
>      Chris, can you conclude this discussion?
> 
> #515 Relaxing HasField constraints
>      2022-08-01: Assigned to Tom
>      2022-08-10: Tom suggests acceptance
>      Still no comments. Tom, please drive this discussion!
> 
> #522: Or Patterns
>      2022-08-08: Assigned to Richard
>      2022-08-19: Richard recommends acceptance
>      2022-10-18: Last message
>      Richard, is this discussion converging?
> 
> #451: WARNING pragma with category, Shepherd: Joachim
>      Acceptance seems imminent 
> 
> ## Waiting for shepherd recommendation
> 
> #330: Decorate exceptions with backtrace information, Shepherd: Vlad
>      2022-06-25: Assignd to Vlad
>      This seems to have fallen through the cracks.
>      Vlad, please make a recommendation!
> 
> #512: NoFieldSelectors as datatype annotation, Shepherd: Vlad
>      2022-09-03: Assignd to Baldur
>      2022-10-02: Reassignd to Vlad
> 
> #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
> 
> #532: Clean up implicit binding, Shepherd: Arnaud   
>      2022-08-23: Assigned to Arnaud
>      Sent back for revision
>      2022-11-27: Resubmitted
> 
> #540: parallelism semaphores, Shepherd: Eric 
>      2022-11-08: Assigned to Adam
>      2022-11-17: Re-assigned to Eric
> 
> #546: Make Symbol a newtype over String, Shepherd: Chris
>      2022-11-18: Assigned to Chris
> 
> #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/20221128/f1e87d41/attachment.html>

From marlowsd at gmail.com  Tue Nov 29 10:14:28 2022
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 29 Nov 2022 10:14:28 +0000
Subject: [ghc-steering-committee] #451: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <CAJKmMz8hjSRk=SKFC1b=L7TjjBH1=FA-WGyTQO+p2VNoNyNkDQ@mail.gmail.com>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
 <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>
 <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de>
 <CAJKmMz8hjSRk=SKFC1b=L7TjjBH1=FA-WGyTQO+p2VNoNyNkDQ@mail.gmail.com>
Message-ID: <CANsrgP+Pm7WaFGyUk6gAiF3csZ_wBVDgSdGVYs1TUbZa+tS20A@mail.gmail.com>

I'd like to see the pragma be `{-# WARNING [partial] head #-}` without the
`x-` prefix, because
1. I'm not in favour of compulsory (and therefore redundant) extra syntax
2. I don't think there would be much confusion about which flag to use,
because the flag is literally included in the warning/error message from
the compiler.

I don't have a strong opinion about whether it's `-Wx-partial` or something
else.

Cheers
Simon

On Mon, 21 Nov 2022 at 23:18, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Ah, now I understand.   I think the proposal would be stronger if the
> Proposed Change Spec contains something like this
>
>    - The warning category in a WARNING pragma must begin with "x-"; e.g.
>    `{-# WARNING [x-partial] head #-}`.  The reason for this is so that, the
>    command line options `-Wx-partial` and `-Wno-x-partial` can readily be
>    distinguished from the existing large number of built-in warning
>    categories, such as `-Wtabs`, `-Wdodgy-import`, `-Winaccessible-code` etc.
>    See the user manual section
>    <https://ghc.gitlab.haskell.org/ghc/doc/users_guide/using-warnings.html?highlight=warning#warnings-and-sanity-checking>for
>    a complete list.
>
> Doubtless this is said already, but I did not absorb it.
>
> An alternative you don't describe is to use a different -W flag to turn on
> and off these user-specified warnings.  E.g. `-Wext:partial`,
> `-Wext:no-partial`.  We don't think of this as a category sometimes called
> `partial` and sometimes called `ext:partial`.  Rather we think of two flags
> `-W` and `-Wext`.    I know this is equivalent to what the proposal said
> originally; now I understand it better I can see the original thinking.
>
> I don't feel strongly; but once decided, it needs clear exposition.
>
> Simon
>
> On Mon, 21 Nov 2022 at 20:32, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Montag, dem 21.11.2022 um 13:42 +0000 schrieb Simon Peyton Jones:
>> > > But to share some color preferences: I think the x- should be in
>> > > the warning pragma, as currently written on GitHub. I also think we
>> > > will soon want to be able to put the warnings into various bins
>> > > (e.g. Wcompat, which seems very very useful for library writers for
>> > > the same reasons it's useful for GHC itself).
>> > >
>> >
>> >
>> > I'm still a bit baffled by the "x-" bit.  It just seems like extra
>> > noise.
>> >
>> > Or is there an (entirely implicit) suggestion that eventually we
>> > might want "y-"  and "z-" prefixes, for some y and z?
>>
>>
>> Are you baffled by the x- appearing in the flags (-Wno-x-partial) or
>> that they also appear in the pragmas as in
>> {-# WARNING [x-partial] "foobar" #-}?
>>
>> The motivation for the former is namespacing: If we don't keep custom
>> warnings apart from those genuinely produced by the compiler, because
>> else it’s unclear what to do with {-# WARNING [tabs] "hehe" #-}.
>> (Last paragraph of section 2)
>>
>> There is a suggestion to have other prefixes later maybe, to
>> distinguish warning categories that should be on by default from those
>> that should go to -Wextra or -Wall etc. (No entirely implicit, though,
>> section 6.3).
>>
>> The motivation for the latter is that some think it’s even more
>> confusiong to have
>>   {-# WARNING [partial] "foobar" #-}
>> but -Wno-x-partial, because now our mental models are confused whether
>> partial or x-partial is the name of that warning category.
>>
>>
>> I agree that this x-foo business isn't particular aesthetic.
>> Alternatives:
>>  * We could simply allow pragmas to use built-in warning categories.
>>    Maybe the library author has a good reason to group their warning
>>    with -Wwrong-do-bind or -Wdodgy-export
>>    (but it seems a rather dangerous and confusing direction.)
>>  * We could not require a prefix, but forbid any built-in warning
>>    categories (i.e. {-# WARNING [tabs] "foo" #-} is a error).
>>
>>    Then library code would have to rename their categories if they
>>    (accidentially) use a category name that a later GHC version starts
>>    to use themselves.
>>  * Library authors don't get to choose category names freely, but
>>    instead GHC maintains a list of allowed categories (starting with
>>    partial, but what else?). This would allow us to document their
>>    meaning precisely for consistency, and would also allow us to set
>>    their default severity (-Wdefault, -Wall etc.).
>>
>> Do any of these alternatives sound better to you?
>>
>>
>>
>> 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/20221129/f040e12a/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Nov 29 11:06:30 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 29 Nov 2022 11:06:30 +0000
Subject: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Decorate
 exceptions with backtrace information (#330)
In-Reply-To: <ghc-proposals/ghc-proposals/pull/330/c1330446106@github.com>
References: <ghc-proposals/ghc-proposals/pull/330@github.com>
 <ghc-proposals/ghc-proposals/pull/330/c1330446106@github.com>
Message-ID: <CAJKmMz9Fytf515zBuXj_A+-=jvbJPwxWUqPeBB4ekvOgdqM9=Q@mail.gmail.com>

Vlad

Thank you for such a thorough job!  You are an example to us all.

Simon

On Tue, 29 Nov 2022 at 10:56, Vladislav Zavialov <notifications at github.com>
wrote:

> Hi @bgamari <https://github.com/bgamari>! I have finished another round
> of review and identified a few potential improvements.
>
>    1.
>
>    *Proposal structure.* At the moment, the "Proposed Change
>    Specification" section contains a lot of information in addition to the
>    specification itself. It's mixed with exposition and
>    implementation-specific code snippets. Instead, I expect to see a concise
>    list (bulleted or numbered) of proposed changes, as seen from the end-user
>    perspective. Undoubtedly, the rest of the prose is also valuable, so I ask
>    you not to remove it but to distribute it across other sections of the
>    proposal text.
>    2.
>
>    *Make ExceptionContext opaque.* The proposal define ExceptionContext
>    as a wrapper around [SomeExceptionAnnotation], but should we expose
>    this fact to our users? What if we decide to store additional information
>    there? I believe it would be best not to export the data constructor to
>    allow for future changes.
>    3.
>
>    *Remove the Semigroup instance for ExceptionContext*. The annotations
>    are stored in a list, so (<>) is O(n), and that's not good.
>    Furthermore, I can't think of a use case for appending annotations from
>    different exceptions, so there's a simple way to address this: do not
>    define Semigroup or Monoid instances.
>    4.
>
>    *Semantics of ExceptionContext.* The list of SomeExceptionAnnotation
>    is ordered, so we ought to define how users can interpret this order. What
>    does it mean for one annotation to come before another? Here's an idea:
>    introduce an operation similar to checkpoint
>    <https://hackage.haskell.org/package/annotated-exception-0.2.0.4/docs/Control-Exception-Annotated.html#v:checkpoint>
>    from annotated-exceptions:
>
>    annotateIO :: ExceptionAnnotation a => a -> IO r -> IO r
>
>    The order of SomeExceptionAnnotation would reflect the nesting of
>    calls to annotateIO, reflecting the call stack in its own way
>    (separately from the collected backtraces).
>    5.
>
>    *Group backtraces in a record.* If we say that a single element in
>    SomeExceptionAnnotation corresponds to a call to annotateIO, it is
>    somewhat strange to add multiple annotations for a single event of
>    collecting backtraces. After all, what would it mean for the
>    HasCallStack backtraces to come before the CostCentre backtrace or
>    vice versa? So introduce a record to store them together:
>
>      data Backtraces =
>        Backtraces {
>          costCentreBacktrace :: Maybe (Ptr CostCentreStack),
>          hasCallStackBacktrace :: Maybe GHC.Stack.CallStack,
>          executionBacktrace :: Maybe [GHC.ExecutionStack.Location],
>          ipeBacktrace :: Maybe [StackEntry]
>       }
>
>    (I refine this idea in the next suggestion)
>    6.
>
>    *Encode the Backtraces record with GADTs*. The record type Backtraces
>    that I suggest in the previous point introduces a slightly annoying form of
>    code duplication. The proposal already has an enumeration of backtrace
>    mechanisms:
>
>    data BacktraceMechanism
>       = CostCenterBacktraceMech
>       | ExecutionStackBacktraceMech
>       | IPEBacktraceMech
>       | HasCallStackBacktraceMech
>
>    And in the record, we have a field per mechanism, each wrapped in a
>    Maybe. Fortunately, there is an encoding that removes this
>    duplication. Let us index BacktraceMechanism by the representation
>    type of the backtrace:
>
>    data BacktraceMechanism a where
>      CostCentreBacktrace   :: BacktraceMechanism (Ptr CostCentreStack)
>      HasCallStackBacktrace :: BacktraceMechanism GHC.Stack.CallStack
>      ExecutionBacktrace    :: BacktraceMechanism [GHC.ExecutionStack.Location]
>      IPEBacktrace          :: BacktraceMechanism [StackEntry]
>
>    Now we can encode the set of enabled mechanisms as a function to Bool
>    and the record of collected backtraces as a function to Maybe a.
>    Something along the lines of:
>
>    type EnabledBacktraceMechanisms = forall a. BacktraceMechanism a -> Booltype Backtraces = forall a. BacktraceMechanism a -> Maybe a
>
>    This isn't as low-tech as a an enum and a record, and I realize that
>    low-tech solutions are appealing in their own way, but in this particular
>    case, I find that GADTs offer a more elegant encoding.
>    7.
>
>    *Hide the implicit parameter behind a synonym*. We choose to pass
>    around the exception context as an implicit parameter, but this should be
>    hidden from the end user. This is the way it's done with HasCallStack,
>    where documentation clearly states:
>
>    NOTE: The implicit parameter ?callStack :: CallStack is an
>    implementation
>    detail and *should not* be considered part of the CallStack API, we may
>    decide to change the implementation in the future.
>
>    Let's do the same and introduce a synonym for exception contexts:
>
>    type HasExceptionContext = (?exceptionContext :: ExceptionContext)
>
>    8.
>
>    *Preserve backtraces on rethrowing*. The way the proposal is currently
>    written, when an exception is caught and rethrown, its old backtrace is
>    dropped and a new one is constructed. This is very bad, because rethrowing
>    happens all the time (e.g. in bracket)! But it is not hard to fix:
>    catch should provide the context to the handler as an implicit
>    parameter, and throw should make use of it:
>
>    catch :: Exception e => IO a -> (HasExceptionContext => e -> IO a) -> IO athrowIO :: (HasExceptionContext, Exception e) => e -> IO a
>
>    What about uses of throwIO where HasExceptionContext has not been
>    provided by catch? Easy: default to an empty context. It shouldn't be
>    hard to add this special case to the solver, since HasCallStack has
>    already set a precedent.
>    9.
>
>    *Get rid of toExceptionWithContext*. The proposal introduces a new
>    method to Exception:
>
>    toException :: Exception e => e -> SomeException                                 -- oldtoExceptionWithContext :: Exception e => e -> ExceptionContext -> SomeException  -- new
>
>    But if we are passing the context as a constraint, then we could
>    simply add it to the original method:
>
>    toException :: (HasExceptionContext, Exception e) => e -> SomeException
>
>    There is no need for two methods this way.
>    10.
>
>    *Improvements to throwIONoBacktrace*. Currently the proposal defines
>    NoBacktrace variants of throw and throwIO:
>
>    throwNoBacktrace   :: forall e a. (Exception e) => e -> athrowIONoBacktrace :: forall e a. (Exception e) => e -> a
>
>    The idea is to allow users to opt out of backtraces for
>    non-exceptional control flow. But the problem is that this choice is not
>    recorded anywhere in the exception, so when the exception is caught and
>    rethrown, it will have unwanted backtraces added to it.
>
>    One solution is to add a Bool flag to ExceptionContext to record the
>    choice of not collecting the backtraces, so that they are not collected
>    when the exception is rethrown. In fact, we could avoid the duplication of
>    throw and throwIO this way:
>
>    backtracesEnabled :: HasExceptionContext => BoolenableBacktraces, disableBacktraces :: (HasExceptionContext => r) -> (HasExceptionContext => r)
>    throw :: (HasExceptionContext, Exception e) => e -> IO athrowIO :: (HasExceptionContext, Exception e) => e -> IO a
>
>    throw and throwIO can check for backtracesEnabled before calling
>    collectBacktraces. The users would write something along the lines of:
>
>    disableBacktraces $
>      throwIO MyControlFlowException
>
>    And the choice to disable backtraces would be carried along the
>    exception in its context.
>
> Hopefully, I have not missed anything. In the process of writing this
> review, I took a stab at rewriting the "Proposed Change Specification"
> section in accordance with all of the suggestions above, mainly to convince
> myself that the combination of those suggestions forms a coherent design.
> You can find it here:
> https://gist.github.com/int-index/750c6c292eb8266729adc61a5812a581. If
> you agree with my comments, feel free to incorporate the updated
> specification (or parts of it) into the proposal.
>
> Thank you!
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/ghc-proposals/ghc-proposals/pull/330#issuecomment-1330446106>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAEOY6ZVMSEXYJ6E3PRAMG3WKXOPHANCNFSM4M3U4KSA>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: <ghc-proposals/ghc-proposals/pull/330/c1330446106 at github.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20221129/5696134c/attachment.html>

From lists at richarde.dev  Tue Nov 29 14:13:00 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 29 Nov 2022 14:13:00 +0000
Subject: [ghc-steering-committee] GHC Steering Committee Status
In-Reply-To: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
References: <c0b035599167abd91fd80f451a1002940ddf2f37.camel@joachim-breitner.de>
Message-ID: <010f0184c3bbdee4-b83ec468-03d9-4351-965a-96edad6d6127-000000@us-east-2.amazonses.com>



> On Nov 27, 2022, at 6:10 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> #522: Or Patterns
>      2022-08-08: Assigned to Richard
>      2022-08-19: Richard recommends acceptance
>      2022-10-18: Last message
>      Richard, is this discussion converging?

Yes, it converged! Please mark as accepted. This one fell off my radar, sorry.

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

From mail at joachim-breitner.de  Tue Nov 29 16:14:18 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 29 Nov 2022 17:14:18 +0100
Subject: [ghc-steering-committee] #541: WARNING pragma with category,
 Recommendation: accept
In-Reply-To: <CANsrgP+Pm7WaFGyUk6gAiF3csZ_wBVDgSdGVYs1TUbZa+tS20A@mail.gmail.com>
References: <96101967a640825f61e52c2aae6c29dd5186f3ff.camel@joachim-breitner.de>
 <010f01849a416c75-213361ee-7955-487e-a782-cda06d19b1dd-000000@us-east-2.amazonses.com>
 <CAJKmMz8MaqQ=NBzp9ZhiDbZQQWOE+SFe3R-R-gd7svxHHU7TDQ@mail.gmail.com>
 <68516f416714774cf430daf762a2f0b616b6230b.camel@joachim-breitner.de>
 <CAJKmMz8hjSRk=SKFC1b=L7TjjBH1=FA-WGyTQO+p2VNoNyNkDQ@mail.gmail.com>
 <CANsrgP+Pm7WaFGyUk6gAiF3csZ_wBVDgSdGVYs1TUbZa+tS20A@mail.gmail.com>
Message-ID: <c4d7adf4057ec4fa8d8b417bf9fa3cf0549bec26.camel@joachim-breitner.de>

Hi,

Am Dienstag, dem 29.11.2022 um 10:14 +0000 schrieb Simon Marlow:
> I'd like to see the pragma be `{-# WARNING [partial] head #-}`
> without the `x-` prefix, because 
> 1. I'm not in favour of compulsory (and therefore redundant) extra
> syntax
> 2. I don't think there would be much confusion about which flag to
> use, because the flag is literally included in the warning/error
> message from the compiler. 

looks like we are generally in favor of this proposal, while this
particular shed’s wall color causes discussion.

Arnaud suggested to use the namespace’d name of the category in both
the flags and the pragma  (i.e. [x-partial], [deprecations], to match
-Werror=x-partial, -Werror=deprecations), which resonated with Adam,
Richard and me.

Simon PS was, however, baffled by this and Simon M voices a preference
to only allow custom categories, without the the prefix, in pragmas
([partial]) to reduce noise and redundancy.

Happy to hear more voices and accept with whatever the majority of
voices said they’d prefer (without formal votes, doesn’t seem to be
worth it), assuming nobody thinks either way is a showstopper.


Minor point: Note that it’s not compulsory: The proposal (as it stands)
does allow {-# WARNING [deprecations] -#}, which corresponds to, say, 
-Werror=deprecations, _not_ -Werror=x-deprecations. 

If we’d do away with the explicit x- prefix in pragmas and add it
implicitly, we should probably change Point 3 of the proposed change
specification to not say that a pragma without category is treated like
{-# WARNING [deprecations] #-}, but simply state that it’s then
controlled by the (built-in, non x-’ed) “deprecations” category, even
if the same effect cannot be achieved syntactically with an explicit
category.


Cheers,
Joachim

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


From vlad.z.4096 at gmail.com  Wed Nov 30 11:08:04 2022
From: vlad.z.4096 at gmail.com (Vladislav Zavialov)
Date: Wed, 30 Nov 2022 14:08:04 +0300
Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype
	annotation, Recommendation: reject
Message-ID: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>

Dear Committee,

Matt Parsons has proposed #512 "NoFieldSelectors as datatype annotation".
Read it here:

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

Background:
An older (accepted and implemented) GHC Proposal #160 "NoFieldSelectors"
introduced a language extension flag to control whether top-level field
selectors for record data types are generated. That is, when the programmer
writes data R = MkR { fld :: Int }, shall we generate a top-level fld :: R
-> Int or not? The answer in #160 is to make this controlled by the
"FieldSelectors" language extension (enabled by default).

Proposal Summary:
In the new GHC Proposal #512, Matt argues that the control provided by the
language extension introduced in #160 is insufficiently fine-grained, since
it applies per-module, not per-definition. Matt has a use case where
declarations are generated by Template Haskell and he would like to disable
generation of field selectors for the generated declarations.

The proposal introduces a new pragma-based annotation to declarations:
  data {-# NoFieldSelectors #-} R = MkR { fld :: Int }

The proposal also introduces constructor-level and field-level annotations:
  data R = {-# NoFieldSelectors #-} MkR { fld :: Int }
  data R = MkR { fld :: {-# NoFieldSelectors #-} Int }

Recommendation:
I recommend rejecting this proposal on multiple grounds.

1. The first reason is the implementation (and maintenance) cost. GHC lacks
generic infrastructure for pragmas, so every additional pragma means that
we add at least the following:
* special support in the parser (and the lexer)
* data structures to represent it in the AST, together with TTG extension
fields
* data structures in the Template Haskell AST and the corresponding
conversion logic between TH and GHC ASTs
Maybe more, this is off the top of my head. And the proposal introduces not
one but three places where a new pragma is allowed. This complexity needs
to be justified.

2. The second reason is the existence of a more compelling alternative. I
mentioned the lack of generic infrastructure for pragmas, but we do have an
accepted proposal for generic annotations: it's #370 "Syntax for
Modifiers". If the proposal switched to syntax introduced in #370, it would
address the first objection. However, the author is unwilling to do so as
long as #370 is not implemented (even though it's an accepted proposal).
The author argues that we could switch to the modifiers syntax in the
future, but it does not actually address my concern: if we get the pragma
syntax, it's going to stay with us forever (that is how things typically
work in GHC), and supporting *both* the pragma and modifiers would be worse
still.

3. The third reason is ideological. Pragmas are syntactically similar to
comments because (ideally) one should be able to ignore them. We use them
to define rewrite rules, to mark fields unpacked, or to add cost centre
annotations, because it only affects the performance/profiling, not the
semantics of the code. But here, a pragma would affect what names are
brought into scope, and as such, it shouldn't really be a pragma
(syntactically).

4. The fourth reason is that an easy workaround is available. Just move
declarations into a separate module with "NoFieldSelectors". I understand
that it might be unsatisfactory and inconvenient, but it works and I'm
weighing it against the maintenance cost mentioned in (1).

To summarize, I'm not thrilled about adding a feature that (1) imposes
maintenance costs on GHC, (2) could be done better, (3) uses inappropriate
syntax, and (4) has a readily available workaround. I recognize the
author's motivation but I believe their use case can be addressed in a more
principled way using #370 Modifiers.

Let me know what you think. Discussion period: 2 weeks.

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

From mail at joachim-breitner.de  Wed Nov 30 16:22:56 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 30 Nov 2022 17:22:56 +0100
Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype
 annotation, Recommendation: reject
In-Reply-To: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>
References: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>
Message-ID: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 30.11.2022 um 14:08 +0300 schrieb Vladislav Zavialov:
> 4. The fourth reason is that an easy workaround is available. Just
> move declarations into a separate module with "NoFieldSelectors". I
> understand that it might be unsatisfactory and inconvenient, but it
> works and I'm weighing it against the maintenance cost mentioned in
> (1).

I wonder if there is another work-around: If the motivation is a module
full of TH-generated data types, and only some of them should get a
FieldSelector, couldn’t TH generate those fieldselectors that are
needed simply as plain functions? 

This makes me wonder: can the effect of NoFieldSelectors be really
undone using a plain function definition, or is there something about
field selectors that is special? Ah, probably the export/import  story…
I assume we don’t (yet?) have a way of bundling them with the type
constructor so that `import TyCon(..)` gets them as well?


I also wonder: Where do we want to steer Haskell here! While not a
strict rule, I believe we _do_ want to avoid, if possible, from
creating many different dialects in the long run, and (usually)
extensions should at least be plausible to become the default
eventually. Is that true for NoFieldSelectors? Do we envision that to
eventually become the default? If so, pragmas for turning it on
selectively don’t seem to be that useful.

(Until two days ago I would have been hesitant to imagine Haskell
without FieldSelectors on by default. Two days I go for the first time
worked on a code base with OverloadedRecordDot, and it felt
surprisingly smooth and elegant. Now I could imagine Haskell in the
long run weaning away from (automatic) field selector functions, and
reaching a future where one uses dot notation (and pattern matching, of
course) to get data out of records.)



About wanting to use modifier syntax instead: I sympathize with Matt’s
hesitancy.  Modifier syntax is not only unimplemented, it is also
untested, and (to me at least) it is unclear it will live up to the
generality it tries to apply to. (For example, we’ll see if using the
syntax of types is always the ergonomic syntax for annotation, if some
annotation really need bespoke syntax; if having types there, which at
least need to be name-resolutioned, may prevent their use in
annotations that affect name resolution; etc. – I digress) So if Matt’s
proposal was more compelling on other grounds, I may have suggested to
allow it in Pragma style.

But Vlad makes good arguments about the suggested changes not really
pulling their weight, and thus I concur with his recommendation.

Cheers,
Joachim



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


From adam at well-typed.com  Wed Nov 30 19:28:59 2022
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 30 Nov 2022 19:28:59 +0000
Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype
 annotation, Recommendation: reject
In-Reply-To: <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de>
References: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>
 <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de>
Message-ID: <414422bd-7085-f244-626a-19711dfd0692@well-typed.com>

On 30/11/2022 16:22, Joachim Breitner wrote:
> Am Mittwoch, dem 30.11.2022 um 14:08 +0300 schrieb Vladislav Zavialov:
>> 4. The fourth reason is that an easy workaround is available. Just
>> move declarations into a separate module with "NoFieldSelectors". I
>> understand that it might be unsatisfactory and inconvenient, but it
>> works and I'm weighing it against the maintenance cost mentioned in
>> (1).
> 
> I wonder if there is another work-around: If the motivation is a module
> full of TH-generated data types, and only some of them should get a
> FieldSelector, couldn’t TH generate those fieldselectors that are
> needed simply as plain functions?

The motivating use case seems to be this:

  * End user code defines a datatype Foo (in a module that may or may 
not have FieldSelectors enabled).

  * They then (perhaps via TH) define a datatype SqlFoo using the same 
field names, for which NoFieldSelectors must apply.

I guess we could say that the end user must set NoFieldSelectors on the 
whole module and then write or have TH code generate selectors for Foo. 
But that feels rather awkward, as does being forced to use separate 
modules. I think it would be much nicer if the code could say "use 
NoFieldSelectors for this specific definition".

It seems to me that the motivation is relatively compelling at the level 
of entire datatype declarations. Being able to toggle NoFieldSelectors 
for individual constructors or fields seems less convincing.


> This makes me wonder: can the effect of NoFieldSelectors be really
> undone using a plain function definition, or is there something about
> field selectors that is special? Ah, probably the export/import  story…
> I assume we don’t (yet?) have a way of bundling them with the type
> constructor so that `import TyCon(..)` gets them as well?

Right, we could imagine explicit bundling of selector functions with 
datatype constructors much as we have for pattern synonyms. That might 
be nice independently, but seems like it would still be annoying for the 
motivating use case though: the end user code will suddenly need the 
export list to explicitly list all the fields in all the datatypes it is 
exporting.


> I also wonder: Where do we want to steer Haskell here! While not a
> strict rule, I believe we _do_ want to avoid, if possible, from
> creating many different dialects in the long run, and (usually)
> extensions should at least be plausible to become the default
> eventually. Is that true for NoFieldSelectors? Do we envision that to
> eventually become the default? If so, pragmas for turning it on
> selectively don’t seem to be that useful.
> 
> (Until two days ago I would have been hesitant to imagine Haskell
> without FieldSelectors on by default. Two days I go for the first time
> worked on a code base with OverloadedRecordDot, and it felt
> surprisingly smooth and elegant. Now I could imagine Haskell in the
> long run weaning away from (automatic) field selector functions, and
> reaching a future where one uses dot notation (and pattern matching, of
> course) to get data out of records.)

I think it is too early to judge this. It's not inconceivable that 
NoFieldSelectors will become preferred in the future, but I think the 
in-between period will be long enough that wanting to set it on specific 
datatypes makes sense.


> About wanting to use modifier syntax instead: I sympathize with Matt’s
> hesitancy.  Modifier syntax is not only unimplemented, it is also
> untested, and (to me at least) it is unclear it will live up to the
> generality it tries to apply to. (For example, we’ll see if using the
> syntax of types is always the ergonomic syntax for annotation, if some
> annotation really need bespoke syntax; if having types there, which at
> least need to be name-resolutioned, may prevent their use in
> annotations that affect name resolution; etc. – I digress) So if Matt’s
> proposal was more compelling on other grounds, I may have suggested to
> allow it in Pragma style.
> 
> But Vlad makes good arguments about the suggested changes not really
> pulling their weight, and thus I concur with his recommendation.

The modifiers situation is very unfortunate. I'm not convinced we should 
insist on holding future proposals to an unimplemented/untested design. 
Perhaps there is a reasonable approach that uses neither pragmas nor 
modifiers?

Suggesting half-baked ideas when responding to a proposal is a bit 
risky, but how about this as an alternative: what if we add a new 
top-level declaration that enables a language extension for a block of 
declarations. I'll use "language" as a keyword here, but obviously the 
exact syntax is up for debate. For example:

   language NoFieldSelectors where
     data SqlFoo = SqlFoo...

This could also be used to resolve existing violations of the 
ideological principle Vlad mentions (that pragmas shouldn't affect 
semantics), such as this one:

   language OverlappingInstances where
     instance C [Int]
     instance C [a]

Now we might not want to allow arbitrary language extensions in local 
"language" blocks, if any may have module-wide effects, but if necessary 
we could whitelist extensions that are allowed to be toggled locally. 
Also, this doesn't address the proposal's suggestion of per-constructor 
or per-field NoFieldSelectors; but I'm less convinced that is needed.

This could also solve a similar problem I have experienced, which is 
that TH declaration splices may need various specific language 
extensions for the declarations they generate. For example, both 
`persistent` and `optics` have TH code that reports errors if required 
extensions are not enabled. As a library author, I'd much rather enable 
extensions locally so my TH code works in more contexts and doesn't 
force users to enable otherwise unneeded extensions at the module level.

What do you think?

Adam


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

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


From mail at joachim-breitner.de  Wed Nov 30 20:37:24 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 30 Nov 2022 21:37:24 +0100
Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype
 annotation, Recommendation: reject
In-Reply-To: <414422bd-7085-f244-626a-19711dfd0692@well-typed.com>
References: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>
 <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de>
 <414422bd-7085-f244-626a-19711dfd0692@well-typed.com>
Message-ID: <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry:
> What do you think?

my initial feeling about `language … where …` is that it is a modifer
of sorts, however
 * with a syntax that may not scale well (hard to target anything
   but a whole set of declarations)
 * looks like it could support any kind of language extension, when
   it probably doesn’t make sense for all of them.
so may not gain much over implementing (parts) of the modifier syntax.

But thinking outside the box:

Isn’t there already a warning flag that GHC implicitly turns off when
working on TH-generated files? So could we use the same machinery and
allow, _without actual surface syntax_, and only via the TH API, toggle
some flags that then should apply or not apply when type-checking the
TH output?

   enableExt :: Extension -> Q ()
   disableExt :: Extension -> Q ()
   
But yes, this also has it’s problems. Soon people will ask for this
ability to scope over just _some_ of the generated declarations. And,
maybe worse, if TH can produce something that doesn’t exist as source,
then it’ll cause headaches for those who need to write splices to file for
cross-compilation…

And the syntax-representable version of this idea is … precisely your
langauges … where … idea :-)

Or we revive local modules, and use that as a then natural way of
scoping language pragmas…

Cheers,
Joachim



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


From adam at well-typed.com  Wed Nov 30 21:18:35 2022
From: adam at well-typed.com (Adam Gundry)
Date: Wed, 30 Nov 2022 21:18:35 +0000
Subject: [ghc-steering-committee] #512: NoFieldSelectors as datatype
 annotation, Recommendation: reject
In-Reply-To: <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de>
References: <CAHZ0NLo7LquQBVGyLfQWobCdsDaQv_RGe6vhzncR4fKRGBP=Kw@mail.gmail.com>
 <494656e83f8d1486621fab153ed8f85f13b82e1b.camel@joachim-breitner.de>
 <414422bd-7085-f244-626a-19711dfd0692@well-typed.com>
 <02620ae95fb4d0a07172c06ffa83281d293e4149.camel@joachim-breitner.de>
Message-ID: <451cf30d-8fc6-a052-0c3d-707b5f7fbc92@well-typed.com>

On 30/11/2022 20:37, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, dem 30.11.2022 um 19:28 +0000 schrieb Adam Gundry:
>> What do you think?
> 
> my initial feeling about `language … where …` is that it is a modifer
> of sorts, however
>   * with a syntax that may not scale well (hard to target anything
>     but a whole set of declarations)
>   * looks like it could support any kind of language extension, when
>     it probably doesn’t make sense for all of them.
> so may not gain much over implementing (parts) of the modifier syntax.

Well, I find it hard to imagine really needing to enable an extension 
for anything smaller than a declaration group. On the other hand, I not 
infrequently want to enable particular extensions only for a few 
specific definitions (AllowAmbiguousTypes comes to mind).

As I understand it, modifiers need to be type-checked before they have 
meaning assigned. This presumably means they cannot change the behaviour 
of the parser, whereas an explicit "language ... where ..." construct 
could do so. And I don't think modifiers can scope over a declaration 
group, only a single declaration?

I agree that we wouldn't necessarily support *all* language extensions 
locally, but I think the list for which this fundamentally does not make 
sense is relatively short (the main ones that come to mind are 
import-related extensions such as ExplicitNamespaces). Others might be 
hard to specify/implement (e.g. Safe Haskell seems tricky) but we could 
simply not support them locally.


> ...
> 
> Or we revive local modules, and use that as a then natural way of
> scoping language pragmas…

There's clearly a relationship to local modules, but that seems like 
more complexity than we need for the problem at hand. I don't see why we 
shouldn't add "language ... where ..." now, then potentially later 
support local (or top-level!) modules with

   language Blah where
     module M where
       ...

After all, {-# LANGUAGE #-} pragmas violate the principle that pragmas 
shouldn't change semantics. ;-)

Cheers,

Adam


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

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