From mail at joachim-breitner.de  Wed Feb  1 09:11:18 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 01 Feb 2023 10:11:18 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: No #. label (#573)
Message-ID: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>

Hi,

implementation work on #170 led to insights that called for small
adjustments to the design, namely to remove dot from characters allowed
in overloaded labels.

The proposal is amended at
https://github.com/ghc-proposals/ghc-proposals/pull/573.

This should be part of 9.6, so I’d like to fast-track this for
acceptance. If you disagree with this process please complain until the
end of the week (Sun Feb 5).

Cheers,
Joachim

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


From mail at joachim-breitner.de  Wed Feb  1 09:11:19 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 01 Feb 2023 10:11:19 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: Warning category
	syntax (#576)
Message-ID: <83805a701a5c888ac34cb771b75a549aecce66cd.camel@joachim-breitner.de>

Hi,

implementation work on warning categories (#541) shows that the
implementation would be much simpler if the category was lexed as a
string literal, and Adam wants to amend his warning category proposal 
to the syntax

    {-# WARNING in "x-some-category" "message" #-}

This amendment is at
https://github.com/ghc-proposals/ghc-proposals/pull/576.

This seems to be changing a minor aspect of the original proposal and
implementation is ready, so I think we can fast-track accepting this.
If you disagree with this process please complain until the end of the
week (Sun Feb 5).

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


From simon.peytonjones at gmail.com  Wed Feb  1 09:29:17 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 1 Feb 2023 09:29:17 +0000
Subject: [ghc-steering-committee] Fast tracked amendment: No #. label
	(#573)
In-Reply-To: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
References: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_BorkCy501iRtqTJXMc5CHHrxjNaDVt5c3Kvn0+YYb=g@mail.gmail.com>

I approve

Simon

On Wed, 1 Feb 2023 at 09:11, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> implementation work on #170 led to insights that called for small
> adjustments to the design, namely to remove dot from characters allowed
> in overloaded labels.
>
> The proposal is amended at
> https://github.com/ghc-proposals/ghc-proposals/pull/573.
>
> This should be part of 9.6, so I’d like to fast-track this for
> acceptance. If you disagree with this process please complain until the
> end of the week (Sun Feb 5).
>
> 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/20230201/0b2ac236/attachment.html>

From arnaud.spiwack at tweag.io  Wed Feb  1 09:29:57 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 1 Feb 2023 10:29:57 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: No #. label
	(#573)
In-Reply-To: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
References: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
Message-ID: <CAGwnsnmB5VcjMnW4J2tbkJb7YzuGuWEZtOgHwJ4QgZ=A_zYBgw@mail.gmail.com>

Good for me. The fix is very conservative, maybe we can have dots in some
positions. But this way we are mostly guaranteed backward compatibility
when we make a more informed decision.

On Wed, 1 Feb 2023 at 10:11, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> implementation work on #170 led to insights that called for small
> adjustments to the design, namely to remove dot from characters allowed
> in overloaded labels.
>
> The proposal is amended at
> https://github.com/ghc-proposals/ghc-proposals/pull/573.
>
> This should be part of 9.6, so I’d like to fast-track this for
> acceptance. If you disagree with this process please complain until the
> end of the week (Sun Feb 5).
>
> 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/20230201/f4bc7702/attachment.html>

From arnaud.spiwack at tweag.io  Wed Feb  1 09:31:11 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Wed, 1 Feb 2023 10:31:11 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: Warning
 category syntax (#576)
In-Reply-To: <83805a701a5c888ac34cb771b75a549aecce66cd.camel@joachim-breitner.de>
References: <83805a701a5c888ac34cb771b75a549aecce66cd.camel@joachim-breitner.de>
Message-ID: <CAGwnsnknf90PNOgmQZkCwoDgXxLMsicuOcg8wKYu0h+mrCLuFg@mail.gmail.com>

Fine with me.

On Wed, 1 Feb 2023 at 10:11, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> implementation work on warning categories (#541) shows that the
> implementation would be much simpler if the category was lexed as a
> string literal, and Adam wants to amend his warning category proposal
> to the syntax
>
>     {-# WARNING in "x-some-category" "message" #-}
>
> This amendment is at
> https://github.com/ghc-proposals/ghc-proposals/pull/576.
>
> This seems to be changing a minor aspect of the original proposal and
> implementation is ready, so I think we can fast-track accepting this.
> If you disagree with this process please complain until the end of the
> week (Sun Feb 5).
>
> 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/20230201/23596c5a/attachment.html>

From lists at richarde.dev  Thu Feb  2 12:40:24 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Thu, 2 Feb 2023 12:40:24 +0000
Subject: [ghc-steering-committee] Proposal #556 recommendation: accept
Message-ID: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>

Hi all,

Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that

  f (MkT @(a :: <<here>>)) = ...

should have the same scoping behavior as

  f (MkT (x :: <<here>>)) = ...

Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.

Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.

I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.

Thanks!
Richard

From mail at joachim-breitner.de  Thu Feb  2 12:57:43 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 02 Feb 2023 13:57:43 +0100
Subject: [ghc-steering-committee] Proposal #556 recommendation: accept
In-Reply-To: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
References: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
Message-ID: <b64c6a5d679f2c4a8b2ff4fabdc757cd6a60f7f2.camel@joachim-breitner.de>

Am Donnerstag, dem 02.02.2023 um 12:40 +0000 schrieb Richard Eisenberg:
> Vlad's amendment makes the proposal what I had intended when I wrote
> #448; I strongly recommend acceptance.

I concur!

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


From simon.peytonjones at gmail.com  Thu Feb  2 13:00:20 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 2 Feb 2023 13:00:20 +0000
Subject: [ghc-steering-committee] Proposal #556 recommendation: accept
In-Reply-To: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
References: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
Message-ID: <CAJKmMz_Yj_H+CMHmEia64yUWK+TSw49n55P47m9_nSFN0YxMvw@mail.gmail.com>

I concur!

Simon

On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg <lists at richarde.dev> wrote:

> Hi all,
>
> Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556,
> an amendment to recently accepted proposal #448 on scoped type variables.
> It adds a nuance saying that
>
>   f (MkT @(a :: <<here>>)) = ...
>
> should have the same scoping behavior as
>
>   f (MkT (x :: <<here>>)) = ...
>
> Note that the first is a kind signature of a
> visible-type-application-in-a-pattern, while the second is a pattern
> signature. The intended scoping rule says that the use of an in-scope type
> variable in these positions is an occurrence, while the use of an
> out-of-scope type variable brings that variable into scope. Vlad's proposal
> corrects the phrasing in the original proposal that aligns the treatment of
> the kind signature with the type it is describing, forbidding e.g. the use
> of a repeated variable in the kind signature.
>
> Vlad's amendment makes the proposal what I had intended when I wrote #448;
> I strongly recommend acceptance.
>
> I think this is a small tweak of a technical detail buried in #448 and
> hope this does not cause widespread debate. I will accept this proposal in
> a week if I don't hear objections.
>
> Thanks!
> Richard
> _______________________________________________
> 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/20230202/84f6fc7d/attachment.html>

From chris at chrisdornan.com  Thu Feb  2 14:31:01 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Thu, 2 Feb 2023 14:31:01 +0000
Subject: [ghc-steering-committee] Proposal #556 recommendation: accept
In-Reply-To: <CAJKmMz_Yj_H+CMHmEia64yUWK+TSw49n55P47m9_nSFN0YxMvw@mail.gmail.com>
References: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
 <CAJKmMz_Yj_H+CMHmEia64yUWK+TSw49n55P47m9_nSFN0YxMvw@mail.gmail.com>
Message-ID: <D7A62609-74CE-410D-8F73-EB6E707172CF@chrisdornan.com>

Me too. +1

> On 2 Feb 2023, at 13:00, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I concur!
> 
> Simon
> 
> On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>> Hi all,
>> 
>> Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that
>> 
>>   f (MkT @(a :: <<here>>)) = ...
>> 
>> should have the same scoping behavior as
>> 
>>   f (MkT (x :: <<here>>)) = ...
>> 
>> Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.
>> 
>> Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
>> 
>> I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.
>> 
>> Thanks!
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Sun Feb  5 16:22:56 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Feb 2023 17:22:56 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
Message-ID: <ac78d9c9e31790ccbbbce11b5e4860d038808d2f.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
> Instead, please cast your vote until Apri 5 (but preferrably earlier)
> on the question:
> 
>   Should we proceed towards GHC2023?

So far we have 

* Chris, Adam and me in favor
* Vlad, Arnaud and Simon PJ against

and silence from the rest. And I just noticed that I wrote “April 5”
when I meant “February 5” (for the usual 2 week period). Ups, sorry.

So in theory maybe the others were planning to respond later?

Anyways, given that there is neither consensus (so it’s not clear what
to do), nor much discussion (so it’s not clear that many care), in the
interest of getting things done, I’ll just declare this as rejected –
it’s not a bike-shedding-like issue where close votes are a good way to
make a call, but it’s rather something that, if it happens, should have
broad support in the committee anyways.

(If this was premature and overreachy and suddenly a strong majority in
favor emerges we can still change our collective mind.)

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sun Feb  5 16:25:40 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Feb 2023 17:25:40 +0100
Subject: [ghc-steering-committee] By-law change: Allow self-nominations
In-Reply-To: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
References: <8e2e35d17a90475153788efef4d3429fb5778f2a.camel@joachim-breitner.de>
Message-ID: <e127d48341eb5a7605bb1ecbdadd52fe35d5b422.camel@joachim-breitner.de>

Hi,

Am Montag, dem 23.01.2023 um 15:24 +0100 schrieb Joachim Breitner:
> our current by-law kinda bind our hands in case some motivated comes
> along and would like to join the committee, and Simon PJ suggested that
> we should give us the discretion to hold membership votes out-of-season
> as well. The suggested wording change is in
> https://github.com/ghc-proposals/ghc-proposals/pull/572
> 
> Please discuss and cast your vote within two weeks (preferably earlier,
> as you can guess this change is not happening completely out of the
> blue.)

Simon, Vlad, Chris, Arnaud and me are in favor, so I think we can
accept this one. Arnaud suggested two clarifications on the Github
threat, I’ll include them.

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sun Feb  5 16:42:45 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Feb 2023 17:42:45 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: No #. label
 (#573)
In-Reply-To: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
References: <1e8df61d5febb5cc2c0325f2404eac50c7e334a1.camel@joachim-breitner.de>
Message-ID: <460340931c456bb1483eb50409384cf1825cb7bd.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 01.02.2023 um 10:11 +0100 schrieb Joachim Breitner:
> This should be part of 9.6, so I’d like to fast-track this for
> acceptance. If you disagree with this process please complain until the
> end of the week (Sun Feb 5).

fasttracked!

Cheers,
Joachim

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


From mail at joachim-breitner.de  Sun Feb  5 16:46:04 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 05 Feb 2023 17:46:04 +0100
Subject: [ghc-steering-committee] Fast tracked amendment: Warning
 category syntax (#576)
In-Reply-To: <83805a701a5c888ac34cb771b75a549aecce66cd.camel@joachim-breitner.de>
References: <83805a701a5c888ac34cb771b75a549aecce66cd.camel@joachim-breitner.de>
Message-ID: <2710c17041a0c706c5fcda033509bbc241b8bdd1.camel@joachim-breitner.de>

Hi,

Am Mittwoch, dem 01.02.2023 um 10:11 +0100 schrieb Joachim Breitner:
>     {-# WARNING in "x-some-category" "message" #-}
> 
> This amendment is at
> https://github.com/ghc-proposals/ghc-proposals/pull/576.
> 
> This seems to be changing a minor aspect of the original proposal and
> implementation is ready, so I think we can fast-track accepting this.
> If you disagree with this process please complain until the end of the
> week (Sun Feb 5).

Arnaud nodded politely, nobody complained, so that’s fast-tracked too.

Cheers,
Joachim

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


From chris at chrisdornan.com  Sun Feb  5 17:33:43 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Sun, 5 Feb 2023 17:33:43 +0000
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <ac78d9c9e31790ccbbbce11b5e4860d038808d2f.camel@joachim-breitner.de>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <ac78d9c9e31790ccbbbce11b5e4860d038808d2f.camel@joachim-breitner.de>
Message-ID: <CA98E4EB-DF13-4C3A-B3F3-4830A7B34258@chrisdornan.com>

Although I was in favour of us proceeding I agree that in the face of such ambivalence it is probably best to assume that we won't  'release' GHC2023.

I am hedging a bit -- those of us in favour might muster an argument later in the year and explain exactly what we want GHC2023 for, and turn the doubters into believers, but the onus will be on us to do that, and until then we can focus on other matters.

> On 5 Feb 2023, at 16:22, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
>> Instead, please cast your vote until Apri 5 (but preferrably earlier)
>> on the question:
>> 
>>   Should we proceed towards GHC2023?
> 
> So far we have 
> 
> * Chris, Adam and me in favor
> * Vlad, Arnaud and Simon PJ against
> 
> and silence from the rest. And I just noticed that I wrote “April 5”
> when I meant “February 5” (for the usual 2 week period). Ups, sorry.
> 
> So in theory maybe the others were planning to respond later?
> 
> Anyways, given that there is neither consensus (so it’s not clear what
> to do), nor much discussion (so it’s not clear that many care), in the
> interest of getting things done, I’ll just declare this as rejected –
> it’s not a bike-shedding-like issue where close votes are a good way to
> make a call, but it’s rather something that, if it happens, should have
> broad support in the committee anyways.
> 
> (If this was premature and overreachy and suddenly a strong majority in
> favor emerges we can still change our collective mind.)
> 
> 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 lists at richarde.dev  Mon Feb  6 01:55:48 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 6 Feb 2023 01:55:48 +0000
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <CA98E4EB-DF13-4C3A-B3F3-4830A7B34258@chrisdornan.com>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <ac78d9c9e31790ccbbbce11b5e4860d038808d2f.camel@joachim-breitner.de>
 <CA98E4EB-DF13-4C3A-B3F3-4830A7B34258@chrisdornan.com>
Message-ID: <010f0186246fbd56-760a7532-1501-483f-90dc-b0ad3b40c351-000000@us-east-2.amazonses.com>

Instead of focusing narrowly on GHC2023, I would much rather harness the activity that arose over https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing and get that discussion in a state where we can actually turn it into something resembling a policy. I think that's why I didn't vote on the GHC2023 question. I feel unable to have an opinion about GHC2023 until we sort out the larger question.

I seem to recall some email suggesting Arnaud would pilot the discussion to a conclusion. That would be great. But if I'm either dreaming that or Arnaud is actually unavailable, I can volunteer to do this. This would take the place of active work within GHC for me for a few weeks, but I actually think that's OK and a good use of my time.

Richard

> On Feb 5, 2023, at 12:33 PM, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> Although I was in favour of us proceeding I agree that in the face of such ambivalence it is probably best to assume that we won't  'release' GHC2023.
> 
> I am hedging a bit -- those of us in favour might muster an argument later in the year and explain exactly what we want GHC2023 for, and turn the doubters into believers, but the onus will be on us to do that, and until then we can focus on other matters.
> 
>> On 5 Feb 2023, at 16:22, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Hi,
>> 
>> Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
>>> Instead, please cast your vote until Apri 5 (but preferrably earlier)
>>> on the question:
>>> 
>>>  Should we proceed towards GHC2023?
>> 
>> So far we have 
>> 
>> * Chris, Adam and me in favor
>> * Vlad, Arnaud and Simon PJ against
>> 
>> and silence from the rest. And I just noticed that I wrote “April 5”
>> when I meant “February 5” (for the usual 2 week period). Ups, sorry.
>> 
>> So in theory maybe the others were planning to respond later?
>> 
>> Anyways, given that there is neither consensus (so it’s not clear what
>> to do), nor much discussion (so it’s not clear that many care), in the
>> interest of getting things done, I’ll just declare this as rejected –
>> it’s not a bike-shedding-like issue where close votes are a good way to
>> make a call, but it’s rather something that, if it happens, should have
>> broad support in the committee anyways.
>> 
>> (If this was premature and overreachy and suddenly a strong majority in
>> favor emerges we can still change our collective mind.)
>> 
>> Cheers,
>> Joachim
>> 
>> -- 
>> Joachim Breitner
>> mail at joachim-breitner.de
>> http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From mail at joachim-breitner.de  Wed Feb  8 19:48:10 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Wed, 08 Feb 2023 20:48:10 +0100
Subject: [ghc-steering-committee] Welcome Moritz Angermann
Message-ID: <fa3fa548139938b4a615b3f1301a87522893b9e1.camel@joachim-breitner.de>

Hello everybody,

the committee welcomes Moritz Angermann as our newest member!

Cheers,
Joachim

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


From simon.peytonjones at gmail.com  Wed Feb  8 20:30:11 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 8 Feb 2023 20:30:11 +0000
Subject: [ghc-steering-committee] Welcome Moritz Angermann
In-Reply-To: <fa3fa548139938b4a615b3f1301a87522893b9e1.camel@joachim-breitner.de>
References: <fa3fa548139938b4a615b3f1301a87522893b9e1.camel@joachim-breitner.de>
Message-ID: <CAJKmMz_wwqEnGR_A20VB9Z2pckdUni9P+oBdb4rcD4DveUK6rA@mail.gmail.com>

Welcome Moritz.  I'm delighted that you are joining us.  Thank you!

Simon

On Wed, 8 Feb 2023 at 19:48, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hello everybody,
>
> the committee welcomes Moritz Angermann as our newest member!
>
> 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/20230208/96a31ae6/attachment.html>

From moritz.angermann at gmail.com  Wed Feb  8 23:50:07 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 9 Feb 2023 07:50:07 +0800
Subject: [ghc-steering-committee] Welcome Moritz Angermann
In-Reply-To: <CAJKmMz_wwqEnGR_A20VB9Z2pckdUni9P+oBdb4rcD4DveUK6rA@mail.gmail.com>
References: <fa3fa548139938b4a615b3f1301a87522893b9e1.camel@joachim-breitner.de>
 <CAJKmMz_wwqEnGR_A20VB9Z2pckdUni9P+oBdb4rcD4DveUK6rA@mail.gmail.com>
Message-ID: <CAKfdd-y3YAk-CU5ROHAh9Z_ZyZMBp-TLyWZS9hGHY-K-z1-Jfg@mail.gmail.com>

Thank you everyone!

I’m looking forward to making myself useful!

Cheers,
  Moritz


On Thu, 9 Feb 2023 at 4:29 AM, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Welcome Moritz.  I'm delighted that you are joining us.  Thank you!
>
> Simon
>
> On Wed, 8 Feb 2023 at 19:48, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hello everybody,
>>
>> the committee welcomes Moritz Angermann as our newest member!
>>
>> 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/20230209/782e47a1/attachment.html>

From mail at joachim-breitner.de  Thu Feb  9 21:19:06 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 09 Feb 2023 22:19:06 +0100
Subject: [ghc-steering-committee] Thanks, Tom!
Message-ID: <69c5cc1f872bf7c0068042d5ad5c0726afc5407c.camel@joachim-breitner.de>

Hi,

Tom told me that it’s time for him to step down.

Thanks, Tom, for your service on the committee in the last three years,
and don’t be a stranger to GHC!

(Tom was an “expiring member” anyways since January, but we are still
10 members strong, so this does not trigger a new call for nominations.
The next regular call for nomination will happen next spring when
Richard’s, Vlad’s and my terms expire.)

Cheers,
Joachim

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


From mail at joachim-breitner.de  Thu Feb  9 21:24:53 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 09 Feb 2023 22:24:53 +0100
Subject: [ghc-steering-committee] #515 Relaxing HasField constraints,
	reassigned to Moritz
Message-ID: <50132813cabddef701518918ecbe53bb089a59b8.camel@joachim-breitner.de>

Hi committee,

with Tom stepping down, we have to re-assign this proposal:

#515 Relaxing HasField constraints
https://github.com/ghc-proposals/ghc-proposals/pull/515
https://github.com/ocharles/ghc-proposals/blob/hasfield/proposals/0000-hasfield-incoherence.rst

It was submitted in August 2022, and Tom recommended acceptance.
Richard raised technical issues with it.

I’d like to assign it to Adam, but he’s a co-author…

So in best tradition of our committee, I’ll assign this to Moritz.

Moritz, can you help drive the discussion, here and/or on Github?
Maybe the proposal needs to be revised, based on Richard’s objections?
Then you can label it as “needs-revision” until the authors come back
to you.

Cheers,
Joachim


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


From lists at richarde.dev  Fri Feb 10 00:17:28 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 10 Feb 2023 00:17:28 +0000
Subject: [ghc-steering-committee] Proposal #556 recommendation: accept
In-Reply-To: <D7A62609-74CE-410D-8F73-EB6E707172CF@chrisdornan.com>
References: <010f018612247321-d9115915-b136-4d70-b1f1-f66fe3130270-000000@us-east-2.amazonses.com>
 <CAJKmMz_Yj_H+CMHmEia64yUWK+TSw49n55P47m9_nSFN0YxMvw@mail.gmail.com>
 <D7A62609-74CE-410D-8F73-EB6E707172CF@chrisdornan.com>
Message-ID: <010f018638af292a-fde45256-2edd-4346-aed7-540541460c72-000000@us-east-2.amazonses.com>

With several votes in favor and nothing against, I declare this to be accepted. Joachim, would you mind merging? I'm in a train and cannot easily do so from here.

Thanks!
Richard

> On Feb 2, 2023, at 9:31 AM, Chris Dornan <chris at chrisdornan.com> wrote:
> 
> Me too. +1
> 
>> On 2 Feb 2023, at 13:00, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
>> 
>> I concur!
>> 
>> Simon
>> 
>> On Thu, 2 Feb 2023 at 12:40, Richard Eisenberg <lists at richarde.dev <mailto:lists at richarde.dev>> wrote:
>> Hi all,
>> 
>> Vlad has proposed https://github.com/ghc-proposals/ghc-proposals/pull/556 <https://github.com/ghc-proposals/ghc-proposals/pull/556>, an amendment to recently accepted proposal #448 on scoped type variables. It adds a nuance saying that
>> 
>>   f (MkT @(a :: <<here>>)) = ...
>> 
>> should have the same scoping behavior as
>> 
>>   f (MkT (x :: <<here>>)) = ...
>> 
>> Note that the first is a kind signature of a visible-type-application-in-a-pattern, while the second is a pattern signature. The intended scoping rule says that the use of an in-scope type variable in these positions is an occurrence, while the use of an out-of-scope type variable brings that variable into scope. Vlad's proposal corrects the phrasing in the original proposal that aligns the treatment of the kind signature with the type it is describing, forbidding e.g. the use of a repeated variable in the kind signature.
>> 
>> Vlad's amendment makes the proposal what I had intended when I wrote #448; I strongly recommend acceptance.
>> 
>> I think this is a small tweak of a technical detail buried in #448 and hope this does not cause widespread debate. I will accept this proposal in a week if I don't hear objections.
>> 
>> Thanks!
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 

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

From arnaud.spiwack at tweag.io  Fri Feb 10 16:00:13 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 10 Feb 2023 17:00:13 +0100
Subject: [ghc-steering-committee] Call for votes: Shall we have GHC2023
In-Reply-To: <010f0186246fbd56-760a7532-1501-483f-90dc-b0ad3b40c351-000000@us-east-2.amazonses.com>
References: <9ae3e8e28ee6c7e3b8a2481d1609861b00a5381c.camel@joachim-breitner.de>
 <ac78d9c9e31790ccbbbce11b5e4860d038808d2f.camel@joachim-breitner.de>
 <CA98E4EB-DF13-4C3A-B3F3-4830A7B34258@chrisdornan.com>
 <010f0186246fbd56-760a7532-1501-483f-90dc-b0ad3b40c351-000000@us-east-2.amazonses.com>
Message-ID: <CAGwnsnkRnJMJRFj6acRCstORz_s=L4tKHLo0gWK-2qRt28F=Tg@mail.gmail.com>

Because I've been very silent here: I've spoken with Richard, and I'll be
the person handling the document, as promised. I really wished I could have
gotten to it earlier, but I've had a very intense couple of weeks which
didn't afford me the sort of focus that this task deserves. That being
said, I have a plan, so a bunch of polls coming to you Very Soon™.

/Arnaud

On Mon, 6 Feb 2023 at 02:56, Richard Eisenberg <lists at richarde.dev> wrote:

> Instead of focusing narrowly on GHC2023, I would much rather harness the
> activity that arose over
> https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing
> and get that discussion in a state where we can actually turn it into
> something resembling a policy. I think that's why I didn't vote on the
> GHC2023 question. I feel unable to have an opinion about GHC2023 until we
> sort out the larger question.
>
> I seem to recall some email suggesting Arnaud would pilot the discussion
> to a conclusion. That would be great. But if I'm either dreaming that or
> Arnaud is actually unavailable, I can volunteer to do this. This would take
> the place of active work within GHC for me for a few weeks, but I actually
> think that's OK and a good use of my time.
>
> Richard
>
> > On Feb 5, 2023, at 12:33 PM, Chris Dornan <chris at chrisdornan.com> wrote:
> >
> > Although I was in favour of us proceeding I agree that in the face of
> such ambivalence it is probably best to assume that we won't  'release'
> GHC2023.
> >
> > I am hedging a bit -- those of us in favour might muster an argument
> later in the year and explain exactly what we want GHC2023 for, and turn
> the doubters into believers, but the onus will be on us to do that, and
> until then we can focus on other matters.
> >
> >> On 5 Feb 2023, at 16:22, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
> >>
> >> Hi,
> >>
> >> Am Sonntag, dem 22.01.2023 um 13:40 +0100 schrieb Joachim Breitner:
> >>> Instead, please cast your vote until Apri 5 (but preferrably earlier)
> >>> on the question:
> >>>
> >>>  Should we proceed towards GHC2023?
> >>
> >> So far we have
> >>
> >> * Chris, Adam and me in favor
> >> * Vlad, Arnaud and Simon PJ against
> >>
> >> and silence from the rest. And I just noticed that I wrote “April 5”
> >> when I meant “February 5” (for the usual 2 week period). Ups, sorry.
> >>
> >> So in theory maybe the others were planning to respond later?
> >>
> >> Anyways, given that there is neither consensus (so it’s not clear what
> >> to do), nor much discussion (so it’s not clear that many care), in the
> >> interest of getting things done, I’ll just declare this as rejected –
> >> it’s not a bike-shedding-like issue where close votes are a good way to
> >> make a call, but it’s rather something that, if it happens, should have
> >> broad support in the committee anyways.
> >>
> >> (If this was premature and overreachy and suddenly a strong majority in
> >> favor emerges we can still change our collective mind.)
> >>
> >> Cheers,
> >> Joachim
> >>
> >> --
> >> Joachim Breitner
> >> mail at joachim-breitner.de
> >> http://www.joachim-breitner.de/
> >>
> >> _______________________________________________
> >> ghc-steering-committee mailing list
> >> ghc-steering-committee at haskell.org
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230210/fc33a49b/attachment.html>

From eric at seidel.io  Sun Feb 12 19:01:42 2023
From: eric at seidel.io (Eric Seidel)
Date: Sun, 12 Feb 2023 14:01:42 -0500
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
Message-ID: <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>

Hi Committee,

Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed adding support for a job-server to GHC. 

The goal is to allow Cabal and Stack to make optimal use of system resources when compiling many packages. Currently, the build tools are forced to choose between 

1. parallelizing across packages, but compiling each package single-threaded
2. parallelizing within packages, but compiling packages sequentially

There is no correct choice for all build plans, so the authors propose a lightweight job-server protocol to allow Cabal and GHC to cooperatively decide on the best parallelization strategy.

The implementation is already done and the changes to GHC are supposed to be quite self-contained. At a high level GHC's participation in the protocol is thus:

1. when invoked with -jsem /path/to/job-server, acquire N job tokens from the job server
2. call `setNumCapabilities N`
3. compile as usual
4. before exiting, return the tokens to the job server

There are more details in how GHC chooses how many tokens to request, and more opportunities for optimization, e.g. returning early returning of unneeded tokens, but this is really the essence of the protocol from GHC's perspective.

---

I have two minds about this proposal. On the one hand, it seems likely to leave performance on the table compared to the alternatives discussed. But on the other hand, this proposal has already been implemented and validated by Well-Typed, and it seems like a small amount of additional complexity for GHC to adapt. (Though I'd love for someone with more knowledge of GHC internals to opine on the internal complexity.)

On balance, I think we should accept this proposal and not let the perfect be the enemy of the good.

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

Eric

On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:
> 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/
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From mail at joachim-breitner.de  Sun Feb 12 21:11:13 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 12 Feb 2023 22:11:13 +0100
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
Message-ID: <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>

Hi,

Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
> I have two minds about this proposal. On the one hand, it seems
> likely to leave performance on the table compared to the alternatives
> discussed. But on the other hand, this proposal has already been
> implemented and validated by Well-Typed, and it seems like a small
> amount of additional complexity for GHC to adapt. (Though I'd love
> for someone with more knowledge of GHC internals to opine on the
> internal complexity.)
> 
> On balance, I think we should accept this proposal and not let the
> perfect be the enemy of the good.

I agree. Especially given that there is an implementation, I see no
good reason why we shouldn’t trust the implementors and authors’s good
sense in their design choices.

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


From moritz.angermann at gmail.com  Mon Feb 13 01:45:37 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Mon, 13 Feb 2023 09:45:37 +0800
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
Message-ID: <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>

> On balance, I think we should accept this proposal and not let the
perfect be the enemy of the good.

I agree with this. An incremental improvement is an improvement. And if
need/interest/funding is there can be iterated upon.

On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hi,
>
> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
> > I have two minds about this proposal. On the one hand, it seems
> > likely to leave performance on the table compared to the alternatives
> > discussed. But on the other hand, this proposal has already been
> > implemented and validated by Well-Typed, and it seems like a small
> > amount of additional complexity for GHC to adapt. (Though I'd love
> > for someone with more knowledge of GHC internals to opine on the
> > internal complexity.)
> >
> > On balance, I think we should accept this proposal and not let the
> > perfect be the enemy of the good.
>
> I agree. Especially given that there is an implementation, I see no
> good reason why we shouldn’t trust the implementors and authors’s good
> sense in their design choices.
>
> 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/20230213/44c45661/attachment.html>

From chris at chrisdornan.com  Mon Feb 13 16:23:47 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Mon, 13 Feb 2023 16:23:47 +0000
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
 <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>
Message-ID: <2B62E931-919C-4974-9386-33B3DC3F2865@chrisdornan.com>

I have wanted this for many years.

I have one question which I put in the thread but it really should not get in the way of making things better -- let's iterate.

+1 from me.

Chris

> On 13 Feb 2023, at 01:45, Moritz Angermann <moritz.angermann at gmail.com> wrote:
> 
> > On balance, I think we should accept this proposal and not let the perfect be the enemy of the good.
> 
> I agree with this. An incremental improvement is an improvement. And if need/interest/funding is there can be iterated upon.
> 
> On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>> Hi,
>> 
>> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
>> > I have two minds about this proposal. On the one hand, it seems
>> > likely to leave performance on the table compared to the alternatives
>> > discussed. But on the other hand, this proposal has already been
>> > implemented and validated by Well-Typed, and it seems like a small
>> > amount of additional complexity for GHC to adapt. (Though I'd love
>> > for someone with more knowledge of GHC internals to opine on the
>> > internal complexity.)
>> > 
>> > On balance, I think we should accept this proposal and not let the
>> > perfect be the enemy of the good.
>> 
>> I agree. Especially given that there is an implementation, I see no
>> good reason why we shouldn’t trust the implementors and authors’s good
>> sense in their design choices.
>> 
>> Cheers,
>> Joachim
>> -- 
>> Joachim Breitner
>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>   http://www.joachim-breitner.de/
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/20230213/4d1ebe24/attachment.html>

From arnaud.spiwack at tweag.io  Tue Feb 14 07:59:12 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Tue, 14 Feb 2023 08:59:12 +0100
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <2B62E931-919C-4974-9386-33B3DC3F2865@chrisdornan.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
 <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>
 <2B62E931-919C-4974-9386-33B3DC3F2865@chrisdornan.com>
Message-ID: <CAGwnsnkzRvuN1vo7g7vAoQ8gPBfvxQKY1AdGi7sYxStfvJWpQQ@mail.gmail.com>

I would like to oppose the argument that “it's already implemented” is a
strong argument for this court. It certainly helps evaluate feasibility,
but we are supposed to evaluate whether something is a good idea.

That being said, considering that
1/ better solutions are hard to design (and even hard to prove better, as
there is not really a standard job server outside of Macos)
2/ it is believed that almost no user will have to use this command
themselves (we expect `-jsem` to be called in a handful of places, such as
in the Cabal tool and possibly in the Stack tool)

I think the benefit will largely outweigh the costs, and am in favour.

On Mon, 13 Feb 2023 at 17:24, Chris Dornan <chris at chrisdornan.com> wrote:

> I have wanted this for many years.
>
> I have one question which I put in the thread but it really should not get
> in the way of making things better -- let's iterate.
>
> +1 from me.
>
> Chris
>
> On 13 Feb 2023, at 01:45, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
> > On balance, I think we should accept this proposal and not let the
> perfect be the enemy of the good.
>
> I agree with this. An incremental improvement is an improvement. And if
> need/interest/funding is there can be iterated upon.
>
> On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de>
> wrote:
>
>> Hi,
>>
>> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
>> > I have two minds about this proposal. On the one hand, it seems
>> > likely to leave performance on the table compared to the alternatives
>> > discussed. But on the other hand, this proposal has already been
>> > implemented and validated by Well-Typed, and it seems like a small
>> > amount of additional complexity for GHC to adapt. (Though I'd love
>> > for someone with more knowledge of GHC internals to opine on the
>> > internal complexity.)
>> >
>> > On balance, I think we should accept this proposal and not let the
>> > perfect be the enemy of the good.
>>
>> I agree. Especially given that there is an implementation, I see no
>> good reason why we shouldn’t trust the implementors and authors’s good
>> sense in their design choices.
>>
>> Cheers,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230214/afa743a8/attachment.html>

From marlowsd at gmail.com  Tue Feb 14 16:52:16 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 14 Feb 2023 16:52:16 +0000
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
Message-ID: <CANsrgPLqBWePuHuAuWqX_2OM1kLaj=Ms9mv-hW_eagjdW8UzKQ@mail.gmail.com>

Yes this seems entirely reasonable, +1.

Simon

On Sun, 12 Feb 2023 at 19:02, Eric Seidel <eric at seidel.io> wrote:

> Hi Committee,
>
> Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed adding
> support for a job-server to GHC.
>
> The goal is to allow Cabal and Stack to make optimal use of system
> resources when compiling many packages. Currently, the build tools are
> forced to choose between
>
> 1. parallelizing across packages, but compiling each package
> single-threaded
> 2. parallelizing within packages, but compiling packages sequentially
>
> There is no correct choice for all build plans, so the authors propose a
> lightweight job-server protocol to allow Cabal and GHC to cooperatively
> decide on the best parallelization strategy.
>
> The implementation is already done and the changes to GHC are supposed to
> be quite self-contained. At a high level GHC's participation in the
> protocol is thus:
>
> 1. when invoked with -jsem /path/to/job-server, acquire N job tokens from
> the job server
> 2. call `setNumCapabilities N`
> 3. compile as usual
> 4. before exiting, return the tokens to the job server
>
> There are more details in how GHC chooses how many tokens to request, and
> more opportunities for optimization, e.g. returning early returning of
> unneeded tokens, but this is really the essence of the protocol from GHC's
> perspective.
>
> ---
>
> I have two minds about this proposal. On the one hand, it seems likely to
> leave performance on the table compared to the alternatives discussed. But
> on the other hand, this proposal has already been implemented and validated
> by Well-Typed, and it seems like a small amount of additional complexity
> for GHC to adapt. (Though I'd love for someone with more knowledge of GHC
> internals to opine on the internal complexity.)
>
> On balance, I think we should accept this proposal and not let the perfect
> be the enemy of the good.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/540
>
> Eric
>
> On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:
> > 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/
> >
> > _______________________________________________
> > 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/20230214/29d6783c/attachment.html>

From chris at chrisdornan.com  Tue Feb 14 17:54:17 2023
From: chris at chrisdornan.com (Chris Dornan)
Date: Tue, 14 Feb 2023 17:54:17 +0000
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <CAGwnsnkzRvuN1vo7g7vAoQ8gPBfvxQKY1AdGi7sYxStfvJWpQQ@mail.gmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
 <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>
 <2B62E931-919C-4974-9386-33B3DC3F2865@chrisdornan.com>
 <CAGwnsnkzRvuN1vo7g7vAoQ8gPBfvxQKY1AdGi7sYxStfvJWpQQ@mail.gmail.com>
Message-ID: <E2C44C49-5D3F-4CF0-B261-E06A115AD0BC@chrisdornan.com>

I 100% agree with what Arnaud is saying in general. I think it is just that this particular proposal is so non-disruptive, that engineering issues dominate, and we don't feel it would be productive to have one of our regular exhaustive discussions of the options as it would risk stalling an important initiative to very little good purpose (in this case).

Normally, where the potential fir disruption to the wider Haskell ecosystem is great, whether a proposal has an implementation behind should not be a  consideration (in my view, at least).



> On 14 Feb 2023, at 07:59, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:
> 
> I would like to oppose the argument that “it's already implemented” is a strong argument for this court. It certainly helps evaluate feasibility, but we are supposed to evaluate whether something is a good idea.
> 
> That being said, considering that
> 1/ better solutions are hard to design (and even hard to prove better, as there is not really a standard job server outside of Macos)
> 2/ it is believed that almost no user will have to use this command themselves (we expect `-jsem` to be called in a handful of places, such as in the Cabal tool and possibly in the Stack tool)
> 
> I think the benefit will largely outweigh the costs, and am in favour.
> 
> On Mon, 13 Feb 2023 at 17:24, Chris Dornan <chris at chrisdornan.com <mailto:chris at chrisdornan.com>> wrote:
>> I have wanted this for many years.
>> 
>> I have one question which I put in the thread but it really should not get in the way of making things better -- let's iterate.
>> 
>> +1 from me.
>> 
>> Chris
>> 
>>> On 13 Feb 2023, at 01:45, Moritz Angermann <moritz.angermann at gmail.com <mailto:moritz.angermann at gmail.com>> wrote:
>>> 
>>> > On balance, I think we should accept this proposal and not let the perfect be the enemy of the good.
>>> 
>>> I agree with this. An incremental improvement is an improvement. And if need/interest/funding is there can be iterated upon.
>>> 
>>> On Mon, 13 Feb 2023 at 5:11 AM, Joachim Breitner <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
>>>> Hi,
>>>> 
>>>> Am Sonntag, dem 12.02.2023 um 14:01 -0500 schrieb Eric Seidel:
>>>> > I have two minds about this proposal. On the one hand, it seems
>>>> > likely to leave performance on the table compared to the alternatives
>>>> > discussed. But on the other hand, this proposal has already been
>>>> > implemented and validated by Well-Typed, and it seems like a small
>>>> > amount of additional complexity for GHC to adapt. (Though I'd love
>>>> > for someone with more knowledge of GHC internals to opine on the
>>>> > internal complexity.)
>>>> > 
>>>> > On balance, I think we should accept this proposal and not let the
>>>> > perfect be the enemy of the good.
>>>> 
>>>> I agree. Especially given that there is an implementation, I see no
>>>> good reason why we shouldn’t trust the implementors and authors’s good
>>>> sense in their design choices.
>>>> 
>>>> Cheers,
>>>> Joachim
>>>> -- 
>>>> Joachim Breitner
>>>>   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>>>>   http://www.joachim-breitner.de/
>>>> 
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Thu Feb 16 09:14:06 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 16 Feb 2023 10:14:06 +0100
Subject: [ghc-steering-committee] Please review #536: Type-level literals as
 a separate language extension, Shepherd: Vlad
Message-ID: <fa294c4eaea45a6d27ca01a92999f9e0712fc7ad.camel@joachim-breitner.de>

Dear Committee,

Ross Paterson proposes
Type-level literals as a separate language extension
https://github.com/ghc-proposals/ghc-proposals/pull/536
https://github.com/RossPaterson/ghc-proposals/blob/literals/proposals/0000-type-level-literals.rst

I suggest Vlad to shepherd this, as he has already engaged
with it on Github.

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


Cheers,
Joachim




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


From arnaud.spiwack at tweag.io  Fri Feb 17 14:06:48 2023
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 17 Feb 2023 15:06:48 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
Message-ID: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>

Dear all,

I am to shepherd the making of our language extension policy, working
off our draft document
[
https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/
].
As a prelude to my introduction, I first want to apologise for taking
that long to get back to this subject, time has, I'm afraid, gotten away
from me. Part of the reason, though, is that we've been pulling in
many directions, and I felt it difficult to find a path toward
consensus among all that.

In the time since I accepted the task, I have therefore spent a lot of
time reading through the entire document multiple time, to try and
identify the points where we agree and the points where we
diverge. And try to build a methodology.

If you go to the document, you'll see that I've separated out our
notes after a horizontal line. I will grow the document above the line
with decisions from this mailing list. Hopefully, the process will
make sure that we are in broad agreement that the text does reflect
our collective position.

The way I'm going to proceed is to organise votes. Or maybe they
should rather be seen as surveys. They'll have a bunch of questions,
pertaining to bits of the documents that I want us to converge on. I'll
extract a broad consensus from this survey, and use it to copy
language in the document. I intend to give about a week for each
survey to complete (conveniently, I'll be very far from a computer for
the next week, so I'll be able to tally the results when I come
back). It's going to take a while, but it's a very difficult, and
sensitive, subject.

---

For this first round, I want us to focus on the categorisation of
language extensions as proposed by Richard and Simon M (sections 2.1
and 2.3, respectively, of our draft notes). As I feel that we will
need to have these categories identified in order to discuss the later
points.

Here are the categories that are common to both (consult the document
for more details):

1. Extensions that are either in GHC20xx or could be part of a future
   GHC20xx (e.g. GADTs)
2. Experimental language features (e.g. LinearTypes)
3. Extensions that allow module-wide violation of some general
   principle that holds elsewhere (e.g. OverlappingInstances)
4. Extensions that allow access to deprecated features (e.g.
DatatypeContexts)
5. Extensions that should be compiler flags, which do not actually
   change the accepted language (e.g. Safe)

Richard adds another category

6. Extensions that change the semantics of existing constructs
   (e.g. OverloadedStrings); as opposed to most extensions, which
   create new syntax for the new feature.

Richard's reasoning is twofold 1/ he doesn't believe that they should
be candidate for inclusion in GHC20xx 2/ he believes that they are
problematic for the same sort of reason as we've used to argue against
fork-like behaviour: that to understand the meaning of a piece of code
you need to know what language extensions have been loaded in the
file.

Simon M adds another category

7. Extensions for specialised use-cases (e.g. MagicHash,
   UnboxedTuples)

Simon's reasoning is that these should not be part of GHC20xx. At the
very least they are not intended to. But they do extend the language,
like 1, and unlike 5. Hence they deserve to be categorised separately
from both.

It is worth noting that Richard classifies Strict as a 6 and Simon M
classifies Strict as a 7.

Now the survey.

Keeping in mind that the goal of this categorisation is to classify
the extensions that currently exist, without judgement on whether we
want to have things in these categories or not:

Q1: Are all the categories 1–5 relevant? If you would like to remove
       some categories, which and why (free form)?
Q2: Is category 6 relevant?
Q2.Y: If you found category 6 to be relevant: should it be its own
           category, or should it be a subcategory of 1?
Q2.N: If you found category 6 not to be relevant, in which category
            would you classify OverloadedStrings? What about PolyKinds?
Q3: Is category 7 relevant?
Q3.Y: If you found category 7 to be relevant: should it be its own
           category or should it be a subcategory of 5?
Q3.N: If you found category 7 not to be relevant: in which category
           would you classify MagicHash? What about UnboxedTuples?
 Q4: In which category would you classify Strict?
 Q5: Is there any category that you feel is missing from the list? If
       so, please argue (free form).

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

From mail at joachim-breitner.de  Fri Feb 17 16:40:31 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 17 Feb 2023 17:40:31 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <17c24a192d4711b1987364b75cc922fa80e600ed.camel@joachim-breitner.de>

Hi,

Am Freitag, dem 17.02.2023 um 15:06 +0100 schrieb Arnaud Spiwack:
> I am to shepherd the making of our language extension policy

thanks for guiding us here. I owe you one for taking this up, as to
some extend I have sparked the discussion, but am glad that I don’t
have to work out the solution.


About the questions: I am struggling a bit with the meta question of
what are categorization here. Are we categorization inherent, objective
properties of language extensions (“changes meaning of syntax”, “purely
local effect”, “is guarded by syntax”) or are we already applying the
result of a policy here (“should be in a future GHC20xx”, “ought to be
a compiler flag”)

So let me answer Q5 first:

>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).

I think the categorization we started so far will cause confusing
discussions because they are not mutually exclusive, and it mixes
categorizing inherent properties with categorization policy to be
applied to them.

Here are some inherent, objective properties that I find relevant in
judging the fate of proposed or existing extensions:

 * Is it new-syntax-guarded (e.g. RoleAnnotations),
   or does it affect existing syntax (e.g. OverloadedStrings)
 * Is it a syntactic convenience extension, i.e. its effect can be 
   achieved using normal Haskell or other extensions
   (e.g. NamedFieldPuns, OverloadedStrings, OverlappingInstances),
   or does it add genuinely new abilities.
 * Is it module-local (e.g. OverloadedStrings, most syntactic 
   extensions), or can it affect downstream modules (e.g. LinearTypes, 
   most type system extensions)
 * (maybe more? adherence to our principles? compatibility with #378?)

With these categories safely out of the way on their own axes, we can
now look at the subjective, policy-like categories, where the list of
extensions becomes a (possibly debate heavy) judgement call, such as:
 
 * Is in GHC20xx
 * Should surely be in a future GHC20xx.
 * Yet unclear if it should be in a future GHC20xx (aka experimental)
 * Should definitely not be in a future GHC20xx, because
   - its effects can be achieved using other means and the others means
     are preferable (e.g. OverlappingInstances)
   - deprecated feature
   - should have been a flag
   - special use-case that can’t be default, but still worth supporting

With this in mind, let me try to answer the questions

> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?

I think we need to distinguish between

   * is in GHC20xx
   * could be in a future GHC20xx
   
as presumably we might have different stability expectations for these
two.

Furthermore, since  “experimental like LinearTypes” surely doesn’t
exclude “could be part of a future GHC20xx”, so maybe the wording
should be
 * experimental, meaning “we don’t know yet if we would want it in a
   future GHC20xx”
vs. 
 * “we are fairly sure we want this to be in a future GHC20xx”

> Q2: Is category 6 relevant?
> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?

Relevant, but on a separate axis (see above).



> Q3: Is category 7 relevant?
> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?

I don’t mind grouping 7 and 5 together.

>  Q4: In which category would you classify Strict?

That’s a tough one. It’s a language dialect that we likely don’t want
to be the default, but it’s likely useful to some. I’m leaning towards
saying “it should have been a flag”, if we don’t want a separate
“special use-case worth supporting”.

Whether we want that category at all depends on a bit on the further
discussion (e.g. whether we want to encourage language variants/forks,
or discourage them, and how strongly). So maybe let’s keep the category
for now.


Cheers,
Joachim

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


From eric at seidel.io  Thu Feb 23 17:57:14 2023
From: eric at seidel.io (Eric Seidel)
Date: Thu, 23 Feb 2023 10:57:14 -0700
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <CAGwnsnkzRvuN1vo7g7vAoQ8gPBfvxQKY1AdGi7sYxStfvJWpQQ@mail.gmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
 <5f06b6387759791d8474a041349d1d2802c5b322.camel@joachim-breitner.de>
 <CAKfdd-z6gq2XqgRFeuY-z9czfw2h3CMMXYOvrTGCTB80vgwm2g@mail.gmail.com>
 <2B62E931-919C-4974-9386-33B3DC3F2865@chrisdornan.com>
 <CAGwnsnkzRvuN1vo7g7vAoQ8gPBfvxQKY1AdGi7sYxStfvJWpQQ@mail.gmail.com>
Message-ID: <8ea80c25-4758-4f7b-9a04-af33c1fb879d@app.fastmail.com>

On Tue, Feb 14, 2023, at 00:59, Arnaud Spiwack wrote:
> I would like to oppose the argument that “it's already implemented” is 
> a strong argument for this court. It certainly helps evaluate 
> feasibility, but we are supposed to evaluate whether something is a 
> good idea.

(I know you ultimately support this proposal, but I want to push back a bit on this argument.)

I think it's a bit more nuanced than that. We are supposed to evaluate whether a proposed change will improve GHC compared to the alternatives (one of which is always "do nothing"). This is unavoidably a question of cost/benefit tradeoffs.

One of the costs we must evaluate is implementation cost (others are maintenance cost, language complexity cost, etc). If the implementation is believed to be costly, in terms of time or blast radius, or similarly if nobody has signed up to do the work, we should absolutely discount the proposal compared to other, cheaper alternatives. We may still decide in favor of the more costly option if we believe the benefits outweigh the cost, but we cannot ignore cost as a factor.

In this particular case, my reasoning is the following:

* We have a proposed solution that might capture 80% of the value, but clearly not 100%.
  * The proposed solution has a very low implementation cost (the work is largely done), and appears to have a low maintenance cost (though that should be re-evaluated in the actual MR!).

* There are ideas for alternate solutions that would likely get closer to capturing the full value, BUT
  * They lack a complete design, which means the cost is quite unclear, along many axes.
  * Nobody is offering to flesh out the design, much less commit to the implementation of the alternates.

* Finally, as far as I can tell, nothing about the current 80% proposal precludes us from pursuing the 100% alternatives later on.

As a result, I view this proposal as a low-cost, incremental improvement that does not conflict with the North Star solution. It would be even better if it moved us closer to the North Star, but my bar for low-cost changes is "non-conflicting".

From eric at seidel.io  Thu Feb 23 18:07:32 2023
From: eric at seidel.io (Eric Seidel)
Date: Thu, 23 Feb 2023 11:07:32 -0700
Subject: [ghc-steering-committee] #540: parallelism semaphores,
 recommendation: *accept*
In-Reply-To: <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
References: <555dcb045377d7eb674c5656ecdb47904f5bdbaf.camel@joachim-breitner.de>
 <2183bf1dbe07ed846d08c0468ff3d49f1f1aca3a.camel@joachim-breitner.de>
 <ec71a6e4b62866add3bf906eb4415fa77810d483.camel@joachim-breitner.de>
 <178bd73a-e54f-46d7-b0fd-6999d61162c5@app.fastmail.com>
Message-ID: <1be75ca3-1b45-424f-b1a1-8f2ef18ced3c@app.fastmail.com>

Hi all,

We have votes in favor from Joachim, Arnaud, Chris, Moritz, and Simon M, and silence otherwise.

Simon PJ, Richard, Vlad, Adam: if you have thoughts or concerns about this proposal, please speak up! 

On Sun, Feb 12, 2023, at 12:01, Eric Seidel wrote:
> Hi Committee,
>
> Douglas Wilson, Sam Derbyshire, and Matthew Pickering have proposed 
> adding support for a job-server to GHC. 
>
> The goal is to allow Cabal and Stack to make optimal use of system 
> resources when compiling many packages. Currently, the build tools are 
> forced to choose between 
>
> 1. parallelizing across packages, but compiling each package single-threaded
> 2. parallelizing within packages, but compiling packages sequentially
>
> There is no correct choice for all build plans, so the authors propose 
> a lightweight job-server protocol to allow Cabal and GHC to 
> cooperatively decide on the best parallelization strategy.
>
> The implementation is already done and the changes to GHC are supposed 
> to be quite self-contained. At a high level GHC's participation in the 
> protocol is thus:
>
> 1. when invoked with -jsem /path/to/job-server, acquire N job tokens 
> from the job server
> 2. call `setNumCapabilities N`
> 3. compile as usual
> 4. before exiting, return the tokens to the job server
>
> There are more details in how GHC chooses how many tokens to request, 
> and more opportunities for optimization, e.g. returning early returning 
> of unneeded tokens, but this is really the essence of the protocol from 
> GHC's perspective.
>
> ---
>
> I have two minds about this proposal. On the one hand, it seems likely 
> to leave performance on the table compared to the alternatives 
> discussed. But on the other hand, this proposal has already been 
> implemented and validated by Well-Typed, and it seems like a small 
> amount of additional complexity for GHC to adapt. (Though I'd love for 
> someone with more knowledge of GHC internals to opine on the internal 
> complexity.)
>
> On balance, I think we should accept this proposal and not let the 
> perfect be the enemy of the good.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/540
>
> Eric
>
> On Wed, Nov 16, 2022, at 14:21, Joachim Breitner wrote:
>> 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/
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

From eric at seidel.io  Thu Feb 23 19:42:17 2023
From: eric at seidel.io (Eric Seidel)
Date: Thu, 23 Feb 2023 12:42:17 -0700
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <afe7f029-ec88-4ff6-a54f-6295f8693698@app.fastmail.com>



On Fri, Feb 17, 2023, at 07:06, Arnaud Spiwack wrote:
> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?

Yes, they all seem relevant.

> Q2: Is category 6 relevant?
> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
> Q3: Is category 7 relevant?
> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?

I think categories 6 and 7 are basically the same thing. I think they are relevant, and that they are distinct from both categories 1 and 5. A while back I suggested adopting Racket's notion of "language level" to enable access to more advanced language features. I think categories 6/7 are this.

>  Q4: In which category would you classify Strict?

6/7

>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).

This feels pretty comprehensive to me.

From marlowsd at gmail.com  Fri Feb 24 14:05:18 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 24 Feb 2023 14:05:18 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <CANsrgPLG=BKjPTHb=BHX0n3cdKgS-6iy3ZsomwnXnr2CFnBgXQ@mail.gmail.com>

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

>
> For this first round, I want us to focus on the categorisation of
> language extensions as proposed by Richard and Simon M (sections 2.1
> and 2.3, respectively, of our draft notes). As I feel that we will
> need to have these categories identified in order to discuss the later
> points.
>
> Here are the categories that are common to both (consult the document
> for more details):
>
> 1. Extensions that are either in GHC20xx or could be part of a future
>    GHC20xx (e.g. GADTs)
> 2. Experimental language features (e.g. LinearTypes)
> 3. Extensions that allow module-wide violation of some general
>    principle that holds elsewhere (e.g. OverlappingInstances)
> 4. Extensions that allow access to deprecated features (e.g.
> DatatypeContexts)
> 5. Extensions that should be compiler flags, which do not actually
>    change the accepted language (e.g. Safe)
>

Just to expand on the rationale here: the categories I proposed (1-5 + 7)
are intended to be *exclusive*: each extension belongs to exactly one of
them. The idea is to give us a way to explain to people why an extension is
or is not part of GHC20xx.

We can have more ways to categorise extensions if we want (e.g. syntactic
vs. not syntactic), and indeed that might be useful. But this one (1-5 + 7)
seemed to me to be most helpful towards the goal of adding some clarity to
the GHC20xx process.


> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?
>

Yes


> Q2: Is category 6 relevant?
>

Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?
>

Whether an extension is syntactic or not is a useful thing to know, but it
doesn't belong alongside 1-5,7 because it's not an exclusive category.
Let's keep it separate.

Note that extensions that add syntax can still often break existing
programs, either because they steal keywords or they give new meaning to
existing syntax. I'm too lazy to search for examples but there are very
probably syntactic extensions that really do change the meaning of an
existing correct program, rather than just cause an existing program to be
rejected. So an extension being syntactic doesn't necessarily make it a
free addition to GHC20xx although it probably does mean it's less risky.

>
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
>

OverloadedStrings: 1
PolyKinds: 1 or 2


> Q3: Is category 7 relevant?
>

Maybe :) It might be possible to put those extensions into 1 if we can
convince ourselves the breakage potential is low enough. It does seem
sensible to have a category for extensions that are mature but so
specialised that we don't plan to include them in GHC20xx. That's different
from 2 (experimental) because we expect those to eventually mature and move
to 1 (or 7, if we keep it).


> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
>

I don't understand how 7 makes sense as a subcategory of 5


> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?
>  Q4: In which category would you classify Strict?
>

5


>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).
>

Cheers
Simon


>
> Best,
> Arnaud
> _______________________________________________
> 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/20230224/44f40d31/attachment.html>

From lists at richarde.dev  Fri Feb 24 18:04:31 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Fri, 24 Feb 2023 18:04:31 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>

Thanks, Arnaud!

> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?

I'm not really sure I understand Category 1. In particular, I think my initial categorization didn't have Arnaud's Category 1, but instead had

8. Extensions that enable only new programs, without changing the semantics of any existing program

This was meant as a counterpoint to 6.

But my initial categorization was non-orthogonal: for example, this Category 8 overlaps with several other categories. In that way, Joachim's argument that we could imagine two axes of categorization -- one technical, one policy-oriented -- is intriguing. For example, -XDatatypeContexts belongs in Category 8 (it's a syntactic extension), but that doesn't mean it should be on-by-default.

Along similar lines, Categories 2 and 3 overlap: we might have an experimental language feature that violates a general principle. (Perhaps UndecidableSuperClasses?)

I tend to think that we'll have an easier time proceeding with 1) orthogonal categories and 2) separation between technical content and policy.

I thus propose the following taxonomy, where each extension gets rated along each axis.

A. Is the extension flag purely a language extension? That is, does the flag enable only new programs, without changing the semantics of any existing programs?

Possible answers: sliding scale 1-5, where 1 means "programs written and widely used today would break and/or change meaning" and 5 means "no programs at all change meaning". It's a sliding scale to account for the fact that e.g. -XTypeFamilies once upon a time meant that all programs retain meanings... except for ones which name a type variable `family`. (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is, I believe, a 5.) So if there are obscure programs that change meaning, we can use 2, 3, and 4 as a way of stating how obscure the programs are. (Higher number = more obscure.)

B. How stable is the extension flag?

Possible answers: sliding scale 1-5, where 1 means "likely to change soon" and 5 means "as unlikely to change as the definition of Monad". (That was chosen deliberately: we *did* change the definition of Monad!) For me, a criterion required to write 5 here would be the possibility of writing down a formal specification of the extension. (So -XGADTs could not be a 5.)

C. Would a user always want to enable this extension for an entire file (as opposed to for local regions)?

Possible answers: sliding scale 1-5, where 1 means "there shouldn't even be a way to enable it for a whole file" and 5 means "no -- a user who wants this flag would want it for the whole file". I would put GADTSyntax as a 5 and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe someone wants to say that one part of a file is more type-y than the rest.

D. How much do we like the extension?

Possible answers: sliding scale 1-5, where 1 means "this shouldn't be here" and 5 means "I want this on by default (ignoring backward compatibility)". -XDatatypeContexts would be a 1: we should never have had that in the language. -XOverloadedStrings would be a 5: even if we don't want it enabled everywhere, it's a vastly useful extension that lots of people depend on.

E. Does the extension flag change the language, as opposed to the operation of the compiler?

Possible answers: sliding scale 1-5, where 1 means "purely about the compiler operation" and 5 means "purely about the language". Most extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put -XTemplateHaskell around a 4, because it's mostly about the language, but it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it affects the way instances are selected, I think.

F. How broad is the use-case for the extension?

Possible answers: sliding scale 1-5, where 1 means "very specialized" and 5 is "broadly useful in many contexts". I would put -XMultiParamTypeClasses at a 5 and -XMagicHash at a 2. I'm struggling to come up with something so specialized as to be worth a 1. I would say -XTypeFamilies and -XGADTs are 4.

I think these questions A-F cover the range of categories Arnaud proposes, while addressing Joachim's and Simon M's desires to keep separate things separate. Having each question have a sliding-scale answer is also nice: it means we can submit our classifications of each extension and just average the results. This avoids time wasted in debate. (You can even submit decimals in the range 1-5, if you like!) I would propose that we highlight and debate any question/extension pair where the (max - min) > 2, as there may be disagreement about what the extension or the question means. And we have a natural way to identify candidates for inclusion in GHC20XX: multiply (or add; I think multiply) the 6 scores for an extension and then set a threshold for acceptance. (I don't think we would do this blindly, at all, but it would offer a wonderful starting-point.)

Having upended the table and made a mess of things, I will now answer the other questions ignoring this new proposal.

> Q2: Is category 6 relevant?

Yes, but it's on the wrong axis.

> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?

I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is about whether we like an extension.

> Q3: Is category 7 relevant?

Yes.

> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?

Hard to say. MagicHash and UnboxedTuples could in theory be flags. But maybe there are other 7s that wouldn't?

>  Q4: In which category would you classify Strict?

5, in that Strict is a compiler flag, but it doesn't certainly change the language.

>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).

I've done that enough already. :)

Richard

From mail at joachim-breitner.de  Fri Feb 24 21:44:10 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Fri, 24 Feb 2023 22:44:10 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
Message-ID: <8e4cc96270869611a32583587b2217f459c8143d.camel@joachim-breitner.de>

Hi,

Am Freitag, dem 24.02.2023 um 18:04 +0000 schrieb Richard Eisenberg:
> I think these questions A-F cover the range of categories Arnaud proposes, while addressing Joachim's and Simon M's desires to keep separate things separate.

I like these categories, they certainly add clarity!

Can we include these category from my mail as well:

G. To what extent is its effect new?

Possible answers:
1 - Code is trivially and better written without the extension
    (e.g. a deprecated extension with a better mechanism around)
3 - The effect can be achieved without it, but very annoyingly
    (e.g. OverloadedStrings, most DerivingX extensions)
4 - The effect can be achieved without it, but needs renamer or 
    typechecker context
    (e.g. RecordWildCards)
5 - There is no way to achieve the effect another way 
    (e.g. Role Annotations)


H. Is the extension local to the module?

Probably quite binary:
1 - It has no effect beyond the current module.
    (most syntactic extensions)
5 – It’s use can affect users of the current module
    (most type extensions, e.g. GADTs, LinearTypes)

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


From lists at richarde.dev  Mon Feb 27 12:38:10 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 27 Feb 2023 12:38:10 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <8e4cc96270869611a32583587b2217f459c8143d.camel@joachim-breitner.de>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <8e4cc96270869611a32583587b2217f459c8143d.camel@joachim-breitner.de>
Message-ID: <010f018692e16525-d39c5b8b-105d-4757-b43e-1e261a0701c4-000000@us-east-2.amazonses.com>

I like G and H but must ask:

Does there exist an extension that has no effect beyond the current module but is more than a 3 on the G scale? Maybe it's OK if the answer is "no", but somehow G and H do not seem fully orthogonal.

Also: the questions in my original list were all constructed so that a higher score would, all else being equal, suggest inclusion as a default extension. I think G is similarly set up. But H is not. Again, that's probably OK, but I wanted to raise the point for others to consider as well.

Richard

> On Feb 24, 2023, at 4:44 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> Am Freitag, dem 24.02.2023 um 18:04 +0000 schrieb Richard Eisenberg:
>> I think these questions A-F cover the range of categories Arnaud proposes, while addressing Joachim's and Simon M's desires to keep separate things separate.
> 
> I like these categories, they certainly add clarity!
> 
> Can we include these category from my mail as well:
> 
> G. To what extent is its effect new?
> 
> Possible answers:
> 1 - Code is trivially and better written without the extension
>    (e.g. a deprecated extension with a better mechanism around)
> 3 - The effect can be achieved without it, but very annoyingly
>    (e.g. OverloadedStrings, most DerivingX extensions)
> 4 - The effect can be achieved without it, but needs renamer or 
>    typechecker context
>    (e.g. RecordWildCards)
> 5 - There is no way to achieve the effect another way 
>    (e.g. Role Annotations)
> 
> 
> H. Is the extension local to the module?
> 
> Probably quite binary:
> 1 - It has no effect beyond the current module.
>    (most syntactic extensions)
> 5 – It’s use can affect users of the current module
>    (most type extensions, e.g. GADTs, LinearTypes)
> 
> 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 Feb 27 16:03:59 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 27 Feb 2023 16:03:59 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
Message-ID: <CAJKmMz-i3BEbxphYpOTv15-pAyTKXkRK3-pVFfGEP5VGh_OHMg@mail.gmail.com>

I am finding this discussion hard to follow.

   - The doc has two different categorisations A, B, C, D...
   - Arnaud's email has a third, 1,2,3...
   - Richard refers to G and H but I don't know what they are.

*Categorisation *is a blunt instrument, because it implies that an
extension is in one category or another, but not both.  It might be better
to think in term of *properties *of an extension.  So imagine a table whose
rows are extensions, and whose columns are properties.

The columns might be:

   - Status:

   - *Stable*: we might eventually expect it to be on-by-default (e.g.
      GADTs, PolyKinds)
      - *Experimental*: might change or be deprecated (E.g. Linear)
      - *Special-purpose*: stable, but will never be on-by-default
      (RebindableSyntax).
      - *Deprecated*: allow access to deprecated features, will not be
      on-by-default (e.g. DeepSubsumption, DatatypeContexts)

I'm not sure if UnboxedTuples is Stable or Special-purpose

   - Backward compatibility
      - *Backward-compatible*.  Switching on this extension will never
      change the meaning of an existing program that already compiles.  Usually
      because the feature is guarded by new syntax (e.g. UnboxedTuples), but
      perhpas also because it accepts more program (e.g. OverlappingInstances)
      - *New-behaviour*.   Switching on this extension may change the
      meaning of an existing program (e.g. Overloaded Strings, PolyKinds)


   - Module-wide: extensions that allow module-wide violation of some
   general principle


This seems more straightforward.   -XStrict would be

   - Special-purpose
   - New-behaviour
   - Module-wide

Simon

On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> I am to shepherd the making of our language extension policy, working
> off our draft document
> [
> https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/
> ].
> As a prelude to my introduction, I first want to apologise for taking
> that long to get back to this subject, time has, I'm afraid, gotten away
> from me. Part of the reason, though, is that we've been pulling in
> many directions, and I felt it difficult to find a path toward
> consensus among all that.
>
> In the time since I accepted the task, I have therefore spent a lot of
> time reading through the entire document multiple time, to try and
> identify the points where we agree and the points where we
> diverge. And try to build a methodology.
>
> If you go to the document, you'll see that I've separated out our
> notes after a horizontal line. I will grow the document above the line
> with decisions from this mailing list. Hopefully, the process will
> make sure that we are in broad agreement that the text does reflect
> our collective position.
>
> The way I'm going to proceed is to organise votes. Or maybe they
> should rather be seen as surveys. They'll have a bunch of questions,
> pertaining to bits of the documents that I want us to converge on. I'll
> extract a broad consensus from this survey, and use it to copy
> language in the document. I intend to give about a week for each
> survey to complete (conveniently, I'll be very far from a computer for
> the next week, so I'll be able to tally the results when I come
> back). It's going to take a while, but it's a very difficult, and
> sensitive, subject.
>
> ---
>
> For this first round, I want us to focus on the categorisation of
> language extensions as proposed by Richard and Simon M (sections 2.1
> and 2.3, respectively, of our draft notes). As I feel that we will
> need to have these categories identified in order to discuss the later
> points.
>
> Here are the categories that are common to both (consult the document
> for more details):
>
> 1. Extensions that are either in GHC20xx or could be part of a future
>    GHC20xx (e.g. GADTs)
> 2. Experimental language features (e.g. LinearTypes)
> 3. Extensions that allow module-wide violation of some general
>    principle that holds elsewhere (e.g. OverlappingInstances)
> 4. Extensions that allow access to deprecated features (e.g.
> DatatypeContexts)
> 5. Extensions that should be compiler flags, which do not actually
>    change the accepted language (e.g. Safe)
>
> Richard adds another category
>
> 6. Extensions that change the semantics of existing constructs
>    (e.g. OverloadedStrings); as opposed to most extensions, which
>    create new syntax for the new feature.
>
> Richard's reasoning is twofold 1/ he doesn't believe that they should
> be candidate for inclusion in GHC20xx 2/ he believes that they are
> problematic for the same sort of reason as we've used to argue against
> fork-like behaviour: that to understand the meaning of a piece of code
> you need to know what language extensions have been loaded in the
> file.
>
> Simon M adds another category
>
> 7. Extensions for specialised use-cases (e.g. MagicHash,
>    UnboxedTuples)
>
> Simon's reasoning is that these should not be part of GHC20xx. At the
> very least they are not intended to. But they do extend the language,
> like 1, and unlike 5. Hence they deserve to be categorised separately
> from both.
>
> It is worth noting that Richard classifies Strict as a 6 and Simon M
> classifies Strict as a 7.
>
> Now the survey.
>
> Keeping in mind that the goal of this categorisation is to classify
> the extensions that currently exist, without judgement on whether we
> want to have things in these categories or not:
>
> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?
> Q2: Is category 6 relevant?
> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
> Q3: Is category 7 relevant?
> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?
>  Q4: In which category would you classify Strict?
>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).
>
> Best,
> Arnaud
> _______________________________________________
> 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/20230227/263aea53/attachment.html>

From mail at joachim-breitner.de  Mon Feb 27 17:30:00 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 27 Feb 2023 18:30:00 +0100
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <010f018692e16525-d39c5b8b-105d-4757-b43e-1e261a0701c4-000000@us-east-2.amazonses.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <8e4cc96270869611a32583587b2217f459c8143d.camel@joachim-breitner.de>
 <010f018692e16525-d39c5b8b-105d-4757-b43e-1e261a0701c4-000000@us-east-2.amazonses.com>
Message-ID: <407b9d6beca74eebb1a39a266dd58e6fbf831cae.camel@joachim-breitner.de>

Hi

Am Montag, dem 27.02.2023 um 12:38 +0000 schrieb Richard Eisenberg:
> Does there exist an extension that has no effect beyond the current
> module but is more than a 3 on the G scale? Maybe it's OK if the
> answer is "no", but somehow G and H do not seem fully orthogonal.

Hmm, maybe runST (if it were a language extension) might be an example
for something that would be very new (imperative features in pure
code), but not visible to downstream users.

FFI could be another one.


> Also: the questions in my original list were all constructed so that
> a higher score would, all else being equal, suggest inclusion as a
> default extension. I think G is similarly set up. But H is not.
> Again, that's probably OK, but I wanted to raise the point for others
> to consider as well.

Oh, yes, probably!

Cheers,
Joachim

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


From lists at richarde.dev  Tue Feb 28 12:23:38 2023
From: lists at richarde.dev (Richard Eisenberg)
Date: Tue, 28 Feb 2023 12:23:38 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
 =?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CAJKmMz-i3BEbxphYpOTv15-pAyTKXkRK3-pVFfGEP5VGh_OHMg@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <CAJKmMz-i3BEbxphYpOTv15-pAyTKXkRK3-pVFfGEP5VGh_OHMg@mail.gmail.com>
Message-ID: <010f018697fa7267-2add601b-267e-4541-968e-934c5d5f1b9c-000000@us-east-2.amazonses.com>



> On Feb 27, 2023, at 11:03 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
> I am finding this discussion hard to follow.  
> The doc has two different categorisations A, B, C, D...
> Arnaud's email has a third, 1,2,3...
> Richard refers to G and H but I don't know what they are.
> Categorisation is a blunt instrument, because it implies that an extension is in one category or another, but not both.  It might be better to think in term of properties of an extension.  So imagine a table whose rows are extensions, and whose columns are properties.

Yes -- I had gotten to a similar place. I propose (essentially) the same structure (though different columns) in my email at https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/003153.html <https://mail.haskell.org/pipermail/ghc-steering-committee/2023-February/003153.html>

A key difference between what I proposed there and what you're suggesting is that my entries are numeric (in the range 1-5) as opposed to symbolic. This allows for the possibility of simply averaging committee members' responses, without the need for protracted debate about whether an extension is e.g. special-purpose or experimental.

Perhaps, though, I have too many columns (labeled with letters in my email).

Richard

> 
> The columns might be:
> Status:
> 
> Stable: we might eventually expect it to be on-by-default (e.g. GADTs, PolyKinds)
> Experimental: might change or be deprecated (E.g. Linear)
> Special-purpose: stable, but will never be on-by-default (RebindableSyntax).
> Deprecated: allow access to deprecated features, will not be on-by-default (e.g. DeepSubsumption, DatatypeContexts)
> I'm not sure if UnboxedTuples is Stable or Special-purpose
> Backward compatibility
> Backward-compatible.  Switching on this extension will never change the meaning of an existing program that already compiles.  Usually because the feature is guarded by new syntax (e.g. UnboxedTuples), but perhpas also because it accepts more program (e.g. OverlappingInstances)
> New-behaviour.   Switching on this extension may change the meaning of an existing program (e.g. Overloaded Strings, PolyKinds)
> Module-wide: extensions that allow module-wide violation of some general principle
> 
> This seems more straightforward.   -XStrict would be 
> Special-purpose
> New-behaviour
> Module-wide
> Simon
> 
> On Fri, 17 Feb 2023 at 14:07, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> Dear all,
> 
> I am to shepherd the making of our language extension policy, working
> off our draft document
> [https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/ <https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/>].
> As a prelude to my introduction, I first want to apologise for taking
> that long to get back to this subject, time has, I'm afraid, gotten away
> from me. Part of the reason, though, is that we've been pulling in
> many directions, and I felt it difficult to find a path toward
> consensus among all that.
> 
> In the time since I accepted the task, I have therefore spent a lot of
> time reading through the entire document multiple time, to try and
> identify the points where we agree and the points where we
> diverge. And try to build a methodology.
> 
> If you go to the document, you'll see that I've separated out our
> notes after a horizontal line. I will grow the document above the line
> with decisions from this mailing list. Hopefully, the process will
> make sure that we are in broad agreement that the text does reflect
> our collective position.
> 
> The way I'm going to proceed is to organise votes. Or maybe they
> should rather be seen as surveys. They'll have a bunch of questions,
> pertaining to bits of the documents that I want us to converge on. I'll
> extract a broad consensus from this survey, and use it to copy
> language in the document. I intend to give about a week for each
> survey to complete (conveniently, I'll be very far from a computer for
> the next week, so I'll be able to tally the results when I come
> back). It's going to take a while, but it's a very difficult, and
> sensitive, subject.
> 
> ---
> 
> For this first round, I want us to focus on the categorisation of
> language extensions as proposed by Richard and Simon M (sections 2.1
> and 2.3, respectively, of our draft notes). As I feel that we will
> need to have these categories identified in order to discuss the later
> points.
> 
> Here are the categories that are common to both (consult the document
> for more details):
> 
> 1. Extensions that are either in GHC20xx or could be part of a future
>    GHC20xx (e.g. GADTs)
> 2. Experimental language features (e.g. LinearTypes)
> 3. Extensions that allow module-wide violation of some general
>    principle that holds elsewhere (e.g. OverlappingInstances)
> 4. Extensions that allow access to deprecated features (e.g. DatatypeContexts)
> 5. Extensions that should be compiler flags, which do not actually
>    change the accepted language (e.g. Safe)
> 
> Richard adds another category
> 
> 6. Extensions that change the semantics of existing constructs
>    (e.g. OverloadedStrings); as opposed to most extensions, which
>    create new syntax for the new feature.
> 
> Richard's reasoning is twofold 1/ he doesn't believe that they should
> be candidate for inclusion in GHC20xx 2/ he believes that they are
> problematic for the same sort of reason as we've used to argue against
> fork-like behaviour: that to understand the meaning of a piece of code
> you need to know what language extensions have been loaded in the
> file.
> 
> Simon M adds another category
> 
> 7. Extensions for specialised use-cases (e.g. MagicHash,
>    UnboxedTuples)
> 
> Simon's reasoning is that these should not be part of GHC20xx. At the
> very least they are not intended to. But they do extend the language,
> like 1, and unlike 5. Hence they deserve to be categorised separately
> from both.
> 
> It is worth noting that Richard classifies Strict as a 6 and Simon M
> classifies Strict as a 7.
> 
> Now the survey.
> 
> Keeping in mind that the goal of this categorisation is to classify
> the extensions that currently exist, without judgement on whether we
> want to have things in these categories or not:
> 
> Q1: Are all the categories 1–5 relevant? If you would like to remove
>        some categories, which and why (free form)?
> Q2: Is category 6 relevant?
> Q2.Y: If you found category 6 to be relevant: should it be its own
>            category, or should it be a subcategory of 1?
> Q2.N: If you found category 6 not to be relevant, in which category
>             would you classify OverloadedStrings? What about PolyKinds?
> Q3: Is category 7 relevant?
> Q3.Y: If you found category 7 to be relevant: should it be its own
>            category or should it be a subcategory of 5?
> Q3.N: If you found category 7 not to be relevant: in which category
>            would you classify MagicHash? What about UnboxedTuples?
>  Q4: In which category would you classify Strict?
>  Q5: Is there any category that you feel is missing from the list? If
>        so, please argue (free form).
> 
> Best,
> Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From marlowsd at gmail.com  Tue Feb 28 14:45:35 2023
From: marlowsd at gmail.com (Simon Marlow)
Date: Tue, 28 Feb 2023 14:45:35 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
Message-ID: <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>

We definitely *could* assign every extension a 1-5 score on 6+ different
axes, but I have to admit the thought of actually doing this gives me a
sinking feeling! Furthermore I'm not sure what we would do with the
results. How do we use the scores to decide what goes into GHC20xx? It
feels like we're creating a great deal of work for ourselves.

The idea of categorising rather than scoring is to shortcut the discussion.
If we know that some extension is experimental (e.g. LinearTypes), it just
goes in the experimental category and we don't need to think about it any
more. If we have an extension that is enabling a deprecated feature, again
we don't need to consider any other aspects.

So, perhaps these axes are useful for extensions that are candidates for
GHC20xx and not in one of the other categories 2-5 in Arnaud's list. But if
we're going to reject extensions from GHC20xx for reasons that are *not*
covered by categories 2-5 in Arnaud's list, then we should think about what
those reasons might be. Is "breaks too many programs" one of them?

Cheers
Simon

On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg <lists at richarde.dev> wrote:

> Thanks, Arnaud!
>
> > Q1: Are all the categories 1–5 relevant? If you would like to remove
> >        some categories, which and why (free form)?
>
> I'm not really sure I understand Category 1. In particular, I think my
> initial categorization didn't have Arnaud's Category 1, but instead had
>
> 8. Extensions that enable only new programs, without changing the
> semantics of any existing program
>
> This was meant as a counterpoint to 6.
>
> But my initial categorization was non-orthogonal: for example, this
> Category 8 overlaps with several other categories. In that way, Joachim's
> argument that we could imagine two axes of categorization -- one technical,
> one policy-oriented -- is intriguing. For example, -XDatatypeContexts
> belongs in Category 8 (it's a syntactic extension), but that doesn't mean
> it should be on-by-default.
>
> Along similar lines, Categories 2 and 3 overlap: we might have an
> experimental language feature that violates a general principle. (Perhaps
> UndecidableSuperClasses?)
>
> I tend to think that we'll have an easier time proceeding with 1)
> orthogonal categories and 2) separation between technical content and
> policy.
>
> I thus propose the following taxonomy, where each extension gets rated
> along each axis.
>
> A. Is the extension flag purely a language extension? That is, does the
> flag enable only new programs, without changing the semantics of any
> existing programs?
>
> Possible answers: sliding scale 1-5, where 1 means "programs written and
> widely used today would break and/or change meaning" and 5 means "no
> programs at all change meaning". It's a sliding scale to account for the
> fact that e.g. -XTypeFamilies once upon a time meant that all programs
> retain meanings... except for ones which name a type variable `family`.
> (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is,
> I believe, a 5.) So if there are obscure programs that change meaning, we
> can use 2, 3, and 4 as a way of stating how obscure the programs are.
> (Higher number = more obscure.)
>
> B. How stable is the extension flag?
>
> Possible answers: sliding scale 1-5, where 1 means "likely to change soon"
> and 5 means "as unlikely to change as the definition of Monad". (That was
> chosen deliberately: we *did* change the definition of Monad!) For me, a
> criterion required to write 5 here would be the possibility of writing down
> a formal specification of the extension. (So -XGADTs could not be a 5.)
>
> C. Would a user always want to enable this extension for an entire file
> (as opposed to for local regions)?
>
> Possible answers: sliding scale 1-5, where 1 means "there shouldn't even
> be a way to enable it for a whole file" and 5 means "no -- a user who wants
> this flag would want it for the whole file". I would put GADTSyntax as a 5
> and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe
> someone wants to say that one part of a file is more type-y than the rest.
>
> D. How much do we like the extension?
>
> Possible answers: sliding scale 1-5, where 1 means "this shouldn't be
> here" and 5 means "I want this on by default (ignoring backward
> compatibility)". -XDatatypeContexts would be a 1: we should never have had
> that in the language. -XOverloadedStrings would be a 5: even if we don't
> want it enabled everywhere, it's a vastly useful extension that lots of
> people depend on.
>
> E. Does the extension flag change the language, as opposed to the
> operation of the compiler?
>
> Possible answers: sliding scale 1-5, where 1 means "purely about the
> compiler operation" and 5 means "purely about the language". Most
> extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put
> -XTemplateHaskell around a 4, because it's mostly about the language, but
> it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it
> affects the way instances are selected, I think.
>
> F. How broad is the use-case for the extension?
>
> Possible answers: sliding scale 1-5, where 1 means "very specialized" and
> 5 is "broadly useful in many contexts". I would put -XMultiParamTypeClasses
> at a 5 and -XMagicHash at a 2. I'm struggling to come up with something so
> specialized as to be worth a 1. I would say -XTypeFamilies and -XGADTs are
> 4.
>
> I think these questions A-F cover the range of categories Arnaud proposes,
> while addressing Joachim's and Simon M's desires to keep separate things
> separate. Having each question have a sliding-scale answer is also nice: it
> means we can submit our classifications of each extension and just average
> the results. This avoids time wasted in debate. (You can even submit
> decimals in the range 1-5, if you like!) I would propose that we highlight
> and debate any question/extension pair where the (max - min) > 2, as there
> may be disagreement about what the extension or the question means. And we
> have a natural way to identify candidates for inclusion in GHC20XX:
> multiply (or add; I think multiply) the 6 scores for an extension and then
> set a threshold for acceptance. (I don't think we would do this blindly, at
> all, but it would offer a wonderful starting-point.)
>
> Having upended the table and made a mess of things, I will now answer the
> other questions ignoring this new proposal.
>
> > Q2: Is category 6 relevant?
>
> Yes, but it's on the wrong axis.
>
> > Q2.Y: If you found category 6 to be relevant: should it be its own
> >            category, or should it be a subcategory of 1?
>
> I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is
> about whether we like an extension.
>
> > Q3: Is category 7 relevant?
>
> Yes.
>
> > Q3.Y: If you found category 7 to be relevant: should it be its own
> >            category or should it be a subcategory of 5?
>
> Hard to say. MagicHash and UnboxedTuples could in theory be flags. But
> maybe there are other 7s that wouldn't?
>
> >  Q4: In which category would you classify Strict?
>
> 5, in that Strict is a compiler flag, but it doesn't certainly change the
> language.
>
> >  Q5: Is there any category that you feel is missing from the list? If
> >        so, please argue (free form).
>
> I've done that enough already. :)
>
> Richard
> _______________________________________________
> 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/20230228/dd1692f9/attachment-0001.html>

From simon.peytonjones at gmail.com  Tue Feb 28 16:30:10 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 28 Feb 2023 16:30:10 +0000
Subject: [ghc-steering-committee] =?utf-8?q?Language_Extension_Policy_?=
	=?utf-8?b?4oCTIFJvdW5kIDE=?=
In-Reply-To: <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
References: <CAGwnsnn=rY=Xzwi23HjQ2zGSRAhtqAS8Xi8Em6M5oqfpG3aYWw@mail.gmail.com>
 <010f018684991b10-761d0bd6-4151-41af-9a56-5cce6ff0aeaa-000000@us-east-2.amazonses.com>
 <CANsrgP+VQLop_UyLudEweB0m1ApaXFDPdnTyTTYm+CYJudYN=g@mail.gmail.com>
Message-ID: <CAJKmMz8KyaM4j5vK+4z3je3hxB2F9bCBUChmFFEJqbuEBMzjgA@mail.gmail.com>

Shall we start with the three columns I described, and the non-scoring
enumerations I suggest, and see where we go?  If it's inadequate we can
elaborate.  But let's not start with too many categories etc.

S

On Tue, 28 Feb 2023 at 14:45, Simon Marlow <marlowsd at gmail.com> wrote:

> We definitely *could* assign every extension a 1-5 score on 6+ different
> axes, but I have to admit the thought of actually doing this gives me a
> sinking feeling! Furthermore I'm not sure what we would do with the
> results. How do we use the scores to decide what goes into GHC20xx? It
> feels like we're creating a great deal of work for ourselves.
>
> The idea of categorising rather than scoring is to shortcut the
> discussion. If we know that some extension is experimental (e.g.
> LinearTypes), it just goes in the experimental category and we don't need
> to think about it any more. If we have an extension that is enabling a
> deprecated feature, again we don't need to consider any other aspects.
>
> So, perhaps these axes are useful for extensions that are candidates for
> GHC20xx and not in one of the other categories 2-5 in Arnaud's list. But if
> we're going to reject extensions from GHC20xx for reasons that are *not*
> covered by categories 2-5 in Arnaud's list, then we should think about what
> those reasons might be. Is "breaks too many programs" one of them?
>
> Cheers
> Simon
>
> On Fri, 24 Feb 2023 at 18:04, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> Thanks, Arnaud!
>>
>> > Q1: Are all the categories 1–5 relevant? If you would like to remove
>> >        some categories, which and why (free form)?
>>
>> I'm not really sure I understand Category 1. In particular, I think my
>> initial categorization didn't have Arnaud's Category 1, but instead had
>>
>> 8. Extensions that enable only new programs, without changing the
>> semantics of any existing program
>>
>> This was meant as a counterpoint to 6.
>>
>> But my initial categorization was non-orthogonal: for example, this
>> Category 8 overlaps with several other categories. In that way, Joachim's
>> argument that we could imagine two axes of categorization -- one technical,
>> one policy-oriented -- is intriguing. For example, -XDatatypeContexts
>> belongs in Category 8 (it's a syntactic extension), but that doesn't mean
>> it should be on-by-default.
>>
>> Along similar lines, Categories 2 and 3 overlap: we might have an
>> experimental language feature that violates a general principle. (Perhaps
>> UndecidableSuperClasses?)
>>
>> I tend to think that we'll have an easier time proceeding with 1)
>> orthogonal categories and 2) separation between technical content and
>> policy.
>>
>> I thus propose the following taxonomy, where each extension gets rated
>> along each axis.
>>
>> A. Is the extension flag purely a language extension? That is, does the
>> flag enable only new programs, without changing the semantics of any
>> existing programs?
>>
>> Possible answers: sliding scale 1-5, where 1 means "programs written and
>> widely used today would break and/or change meaning" and 5 means "no
>> programs at all change meaning". It's a sliding scale to account for the
>> fact that e.g. -XTypeFamilies once upon a time meant that all programs
>> retain meanings... except for ones which name a type variable `family`.
>> (Now, `family` is unconditionally a keyword in types, so -XTypeFamilies is,
>> I believe, a 5.) So if there are obscure programs that change meaning, we
>> can use 2, 3, and 4 as a way of stating how obscure the programs are.
>> (Higher number = more obscure.)
>>
>> B. How stable is the extension flag?
>>
>> Possible answers: sliding scale 1-5, where 1 means "likely to change
>> soon" and 5 means "as unlikely to change as the definition of Monad". (That
>> was chosen deliberately: we *did* change the definition of Monad!) For me,
>> a criterion required to write 5 here would be the possibility of writing
>> down a formal specification of the extension. (So -XGADTs could not be a 5.)
>>
>> C. Would a user always want to enable this extension for an entire file
>> (as opposed to for local regions)?
>>
>> Possible answers: sliding scale 1-5, where 1 means "there shouldn't even
>> be a way to enable it for a whole file" and 5 means "no -- a user who wants
>> this flag would want it for the whole file". I would put GADTSyntax as a 5
>> and OverlappingInstances as a 1. GADTs would (for me) be a 4, because maybe
>> someone wants to say that one part of a file is more type-y than the rest.
>>
>> D. How much do we like the extension?
>>
>> Possible answers: sliding scale 1-5, where 1 means "this shouldn't be
>> here" and 5 means "I want this on by default (ignoring backward
>> compatibility)". -XDatatypeContexts would be a 1: we should never have had
>> that in the language. -XOverloadedStrings would be a 5: even if we don't
>> want it enabled everywhere, it's a vastly useful extension that lots of
>> people depend on.
>>
>> E. Does the extension flag change the language, as opposed to the
>> operation of the compiler?
>>
>> Possible answers: sliding scale 1-5, where 1 means "purely about the
>> compiler operation" and 5 means "purely about the language". Most
>> extensions (e.g. -XPolyKinds) would be 5; -XCPP would be 1. I would put
>> -XTemplateHaskell around a 4, because it's mostly about the language, but
>> it impacts cross-compilation and recompilation avoidance. -XSafe is a 2: it
>> affects the way instances are selected, I think.
>>
>> F. How broad is the use-case for the extension?
>>
>> Possible answers: sliding scale 1-5, where 1 means "very specialized" and
>> 5 is "broadly useful in many contexts". I would put -XMultiParamTypeClasses
>> at a 5 and -XMagicHash at a 2. I'm struggling to come up with something so
>> specialized as to be worth a 1. I would say -XTypeFamilies and -XGADTs are
>> 4.
>>
>> I think these questions A-F cover the range of categories Arnaud
>> proposes, while addressing Joachim's and Simon M's desires to keep separate
>> things separate. Having each question have a sliding-scale answer is also
>> nice: it means we can submit our classifications of each extension and just
>> average the results. This avoids time wasted in debate. (You can even
>> submit decimals in the range 1-5, if you like!) I would propose that we
>> highlight and debate any question/extension pair where the (max - min) > 2,
>> as there may be disagreement about what the extension or the question
>> means. And we have a natural way to identify candidates for inclusion in
>> GHC20XX: multiply (or add; I think multiply) the 6 scores for an extension
>> and then set a threshold for acceptance. (I don't think we would do this
>> blindly, at all, but it would offer a wonderful starting-point.)
>>
>> Having upended the table and made a mess of things, I will now answer the
>> other questions ignoring this new proposal.
>>
>> > Q2: Is category 6 relevant?
>>
>> Yes, but it's on the wrong axis.
>>
>> > Q2.Y: If you found category 6 to be relevant: should it be its own
>> >            category, or should it be a subcategory of 1?
>>
>> I see 6 and 1 not having a relationship: 6 is about syntax, while 1 is
>> about whether we like an extension.
>>
>> > Q3: Is category 7 relevant?
>>
>> Yes.
>>
>> > Q3.Y: If you found category 7 to be relevant: should it be its own
>> >            category or should it be a subcategory of 5?
>>
>> Hard to say. MagicHash and UnboxedTuples could in theory be flags. But
>> maybe there are other 7s that wouldn't?
>>
>> >  Q4: In which category would you classify Strict?
>>
>> 5, in that Strict is a compiler flag, but it doesn't certainly change the
>> language.
>>
>> >  Q5: Is there any category that you feel is missing from the list? If
>> >        so, please argue (free form).
>>
>> I've done that enough already. :)
>>
>> Richard
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230228/711f1383/attachment.html>