Re: [ghc-steering-committee] GHC 2020

Alejandro Serrano Mena

17 Oct 2020 17 Oct '20

3:26 p.m.

I would really like this effort not to die, so I've given the proposal another push. Following the comments from Simon and Joachim, I've re-framed the proposal as laying down a process to create new "language versions" yearly. The idea is to have one of these every year (or 2, or 3, whatever is decided), coinciding with the spring release of GHC. https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202... I think it's important for the community to be involved in the process. If it's clear that an extension is loved by most of the community, that's a big plus for acceptance. In addition, if we come with a list ourselves, we risk having made choices which only show our (biased) point of view. Since in the first round the possible list of extensions may be quite big, we might introduce a "fast-lane process" for this one time, for extensions like EmptyDataDecls or different number formats which seem to have unanimous support. Looking forward to hearing from all of you, Alejandro El lun., 5 oct. 2020 a las 12:07, Joachim Breitner (< mail@joachim-breitner.de>) escribió:

...

Hi,

Am Montag, den 05.10.2020, 10:21 +0100 schrieb Simon Marlow:

...
...
Personally, I would also like to come up with general guidance. Do we expect *any* extension fulfilling the criteria to be included?

Let's be conservative: if there's controversy around a particular extension, default to not including it in GHC2020.

that was a core idea of my original process proposal:

Without long, time-consuming and process-heavy debate around each extension, let’s all of us individually assemble a list of extensions, and turn that into GHC2020. (Maybe for extensions that were not on the list by only one or two give them a chance to reconsider).

This way there is still a chance that it'd become GHC2020, and not GHC2021 or GHC2022, or just fizzle…

And it would hopefully be the a GHC2020 that contains all the low- hanging, non-controversial fruit. This also means that GHC2020 has a good chance of actually getting used. Which means for the work for GHC2021, picking the next set of extensions, is actually relevant and meaningful.

And if something doesn’t make it into GHC2020 that maybe should have? No big deal, as Simon says.

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Attachments:

attachment.html (text/html — 3.5 KB)

Show replies by date

Joachim Breitner

18 Oct 18 Oct

5 p.m.

New subject: GHC 2020

Hi, Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena:

...

I would really like this effort not to die, so I've given the proposal another push. Following the comments from Simon and Joachim, I've re-framed the proposal as laying down a process to create new "language versions" yearly. The idea is to have one of these every year (or 2, or 3, whatever is decided), coinciding with the spring release of GHC. https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-202...

I like the idea of tying this to the Spring release of GHC, this provides a lot of predictability, and also provides a hard deadline, which makes it more likely to make _some_ progress (instead of never achieving the perfect set of extensions). To questions about the criteria: If GHC2021 contains extension Foo, I assume that by default, GHC2020 also contains Foo. But should we allow ourselves to remove something? (I would argue, yes: it should be a rare thing, but if Foo turned out to be problematic, then it seems better to not include it in the next version. Code that still declares 2021 wouldn’t be affected, and code that wants to use GHC2021 and Foo would have to list Foo explicitly, which is arguably a good thing.) Should we make it a hard rule that the extension needs to be supported by the last _n_ versions of GHC? (Would we maybe make point releases of prior versions of GHC to understand -XGHC2021, to make these sets of extensions available to more users faster?)

...

I think it's important for the community to be involved in the process. If it's clear that an extension is loved by most of the community, that's a big plus for acceptance. In addition, if we come with a list ourselves, we risk having made choices which only show our (biased) point of view.

I would hope that with 10 people on the committee, the bias is not too big. And just like GHC proposals that attract discussions are sent back as “needs review”, extensions that cause non-trivial discussion are, by definition, not uncontroversial enough, and should simply be “maybe next year”. Therefore I would like to start with a slimmer, more effective and efficient process that does not involve a full proposal-size discussion on each extension, and does _not_ cause dozends of parallel discussions with the community. So here is a first draft of the “slim proceess”: ============================================================= * 4 months before the expected GHC spring release day of 202x: The Secretary starts the GHC202x process. with an email to the list listing all language extensions supported by GHC that are not in GHC202(x-1), and asking the committee for “votes” (which are also nominations). The secretary also creates a PR with a proposal saying (roughly)

...

GHC202x contains the following extensions in addition to those in GHC202(x-1):

* (none yet)

The community may use comments on this PR to weigh in. * Within two weeks of the start of the process, every committee member is expected to send an initial list of which extensions they expect to be in GHC202x to the mailing list. These mails may contain justifications for why a certain extension is or is not included. After these two weeks, the PR is continuously updated by the secretary to reflect the _current_ tally of votes: An extension is included if it is listed by at least ⅔ (rounded up) of committee members. * Within four weeks, of the start of the process, committee members can change their vote (by email to the list). It is absolutely ok to change your mind based on the explanations in the other members’ emails, or the general comments on the PR. * After these four weeks, the proposal with the current tally gets accepted, and defines GHC202x ============================================================= The goal here is, of course, to efficiently find out which are the uncontentious extensions, without spending a log of time on the contentious ones (which I think we simply want to continue to guard behind their own explicit extension). Meta-process comments: I’ll turn this into an alternative PR to Alejandro’s once he opened his, and we can vote on both together (using ordered voting, I still prefer Alejandro’s process to no GHC2021, this way we don’t step on each other’s toes).

...

Since in the first round the possible list of extensions may be quite big, we might introduce a "fast-lane process" for this one time, for extensions like EmptyDataDecls or different number formats which seem to have unanimous support.

I guess I agree, and I’d just make that the only process :-) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Peyton Jones

19 Oct 19 Oct

3:21 a.m.

New subject: GHC 2020

Some thoughts * I'm willing, but not truly enthusiastic, about the whole idea. The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll. * Do we really want to an annual process? My personal thought is that every two or three years would be plenty often enough. Having a plethora of extensions is confusing. "Is Polykinds in GHC2023?" * When it comes to individual extensions, I'd like to know what the community thinks, since a lot of this is about convenience and stability. I'd suggest a poll of Haskell users. Their votes might guide the committee -- but would not determine the outcome. * I would also suggest that the process be informed by a trawl of Hackage/Stackage to count how widely used each extension is. That is, seek data as well as opinion. * Joachim's 2/3 supermajority seems sensible. An extension should only make it in if there is solid support. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 18 October 2020 22:01 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena: | > I would really like this effort not to die, so I've given the | > proposal another push. Following the comments from Simon and Joachim, | > I've re-framed the proposal as laying down a process to create new | > "language versions" yearly. The idea is to have one of these every | > year (or 2, or 3, whatever is decided), coinciding with the spring | > release of GHC. | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000- | ghc- | 2020.md&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd069 | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681 | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg | pFwJB8wvBxWULqIqFes%3D&reserved=0 | | | I like the idea of tying this to the Spring release of GHC, this | provides a lot of predictability, and also provides a hard deadline, | which makes it more likely to make _some_ progress (instead of never | achieving the perfect set of extensions). | | To questions about the criteria: | | | If GHC2021 contains extension Foo, I assume that by default, GHC2020 | also contains Foo. But should we allow ourselves to remove something? | (I would argue, yes: it should be a rare thing, but if Foo turned out | to be problematic, then it seems better to not include it in the next | version. Code that still declares 2021 wouldn’t be affected, and code | that wants to use GHC2021 and Foo would have to list Foo explicitly, | which is arguably a good thing.) | | | Should we make it a hard rule that the extension needs to be supported | by the last _n_ versions of GHC? | (Would we maybe make point releases of prior versions of GHC to | understand -XGHC2021, to make these sets of extensions available to | more users faster?) | | | > I think it's important for the community to be involved in the | > process. If it's clear that an extension is loved by most of the | > community, that's a big plus for acceptance. In addition, if we come | > with a list ourselves, we risk having made choices which only show | > our (biased) point of view. | | I would hope that with 10 people on the committee, the bias is not too | big. And just like GHC proposals that attract discussions are sent back | as “needs review”, extensions that cause non-trivial discussion are, by | definition, not uncontroversial enough, and should simply be “maybe | next year”. | | Therefore I would like to start with a slimmer, more effective and | efficient process that does not involve a full proposal-size discussion | on each extension, and does _not_ cause dozends of parallel discussions | with the community. So here is a first draft of the “slim proceess”: | | ============================================================= | | * 4 months before the expected GHC spring release day of 202x: | The Secretary starts the GHC202x process. with an email to the list | listing all language extensions supported by GHC that are not in | GHC202(x-1), and asking the committee for “votes” (which are also | nominations). | | The secretary also creates a PR with a proposal saying (roughly) | > GHC202x contains the following extensions in addition to those | > in GHC202(x-1): | > | > * (none yet) | | The community may use comments on this PR to weigh in. | | * Within two weeks of the start of the process, | every committee member is expected to send an | initial list of which extensions they expect to be in GHC202x | to the mailing list. These mails may contain justifications | for why a certain extension is or is not included. | | After these two weeks, the PR is continuously updated by the | secretary to reflect the _current_ tally of votes: | An extension is included if it is listed by at least ⅔ (rounded up) | of committee members. | | * Within four weeks, of the start of the process, | committee members can change their vote (by email to the list). | | It is absolutely ok to change your mind based on the explanations in | the other members’ emails, or the general comments on the PR. | | * After these four weeks, the proposal with the current tally | gets accepted, and defines GHC202x | | ============================================================= | | The goal here is, of course, to efficiently find out which are the | uncontentious extensions, without spending a log of time on the | contentious ones (which I think we simply want to continue to guard | behind their own explicit extension). | | | Meta-process comments: | I’ll turn this into an alternative PR to Alejandro’s once he opened | his, and we can vote on both together (using ordered voting, I still | prefer Alejandro’s process to no GHC2021, this way we don’t step on | each other’s toes). | | | | > Since in the first round the possible list of extensions may be quite | > big, we might introduce a "fast-lane process" for this one time, for | > extensions like EmptyDataDecls or different number formats which seem | > to have unanimous support. | | I guess I agree, and I’d just make that the only process :-) | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d8096 | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd0 | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516 | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL | QKwKyWug5dv9Y5coJcQ%3D&reserved=0

Alejandro Serrano Mena

9:21 a.m.

New subject: GHC 2020

Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on. I like Joachim's proposal, if you all agree that pushing this from the Committee would be well-received by the community. I would prefer to have a single PR coming from the community, maybe integrating that proposal with a few points in which we gather input from the community. Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years. Regards, Alejandro El lun., 19 oct. 2020 a las 9:22, Simon Peyton Jones via ghc-steering-committee () escribió:

...

Some thoughts

* I'm willing, but not truly enthusiastic, about the whole idea. The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

* Do we really want to an annual process? My personal thought is that every two or three years would be plenty often enough. Having a plethora of extensions is confusing. "Is Polykinds in GHC2023?"

* When it comes to individual extensions, I'd like to know what the community thinks, since a lot of this is about convenience and stability. I'd suggest a poll of Haskell users. Their votes might guide the committee -- but would not determine the outcome.

* I would also suggest that the process be informed by a trawl of Hackage/Stackage to count how widely used each extension is. That is, seek data as well as opinion.

* Joachim's 2/3 supermajority seems sensible. An extension should only make it in if there is solid support.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 18 October 2020 22:01 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena: | > I would really like this effort not to die, so I've given the | > proposal another push. Following the comments from Simon and Joachim, | > I've re-framed the proposal as laying down a process to create new | > "language versions" yearly. The idea is to have one of these every | > year (or 2, or 3, whatever is decided), coinciding with the spring | > release of GHC. | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000- | ghc- | 2020.md&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd069 | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681 | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg | pFwJB8wvBxWULqIqFes%3D&reserved=0 | | | I like the idea of tying this to the Spring release of GHC, this | provides a lot of predictability, and also provides a hard deadline, | which makes it more likely to make _some_ progress (instead of never | achieving the perfect set of extensions). | | To questions about the criteria: | | | If GHC2021 contains extension Foo, I assume that by default, GHC2020 | also contains Foo. But should we allow ourselves to remove something? | (I would argue, yes: it should be a rare thing, but if Foo turned out | to be problematic, then it seems better to not include it in the next | version. Code that still declares 2021 wouldn’t be affected, and code | that wants to use GHC2021 and Foo would have to list Foo explicitly, | which is arguably a good thing.) | | | Should we make it a hard rule that the extension needs to be supported | by the last _n_ versions of GHC? | (Would we maybe make point releases of prior versions of GHC to | understand -XGHC2021, to make these sets of extensions available to | more users faster?) | | | > I think it's important for the community to be involved in the | > process. If it's clear that an extension is loved by most of the | > community, that's a big plus for acceptance. In addition, if we come | > with a list ourselves, we risk having made choices which only show | > our (biased) point of view. | | I would hope that with 10 people on the committee, the bias is not too | big. And just like GHC proposals that attract discussions are sent back | as “needs review”, extensions that cause non-trivial discussion are, by | definition, not uncontroversial enough, and should simply be “maybe | next year”. | | Therefore I would like to start with a slimmer, more effective and | efficient process that does not involve a full proposal-size discussion | on each extension, and does _not_ cause dozends of parallel discussions | with the community. So here is a first draft of the “slim proceess”: | | ============================================================= | | * 4 months before the expected GHC spring release day of 202x: | The Secretary starts the GHC202x process. with an email to the list | listing all language extensions supported by GHC that are not in | GHC202(x-1), and asking the committee for “votes” (which are also | nominations). | | The secretary also creates a PR with a proposal saying (roughly) | > GHC202x contains the following extensions in addition to those | > in GHC202(x-1): | > | > * (none yet) | | The community may use comments on this PR to weigh in. | | * Within two weeks of the start of the process, | every committee member is expected to send an | initial list of which extensions they expect to be in GHC202x | to the mailing list. These mails may contain justifications | for why a certain extension is or is not included. | | After these two weeks, the PR is continuously updated by the | secretary to reflect the _current_ tally of votes: | An extension is included if it is listed by at least ⅔ (rounded up) | of committee members. | | * Within four weeks, of the start of the process, | committee members can change their vote (by email to the list). | | It is absolutely ok to change your mind based on the explanations in | the other members’ emails, or the general comments on the PR. | | * After these four weeks, the proposal with the current tally | gets accepted, and defines GHC202x | | ============================================================= | | The goal here is, of course, to efficiently find out which are the | uncontentious extensions, without spending a log of time on the | contentious ones (which I think we simply want to continue to guard | behind their own explicit extension). | | | Meta-process comments: | I’ll turn this into an alternative PR to Alejandro’s once he opened | his, and we can vote on both together (using ordered voting, I still | prefer Alejandro’s process to no GHC2021, this way we don’t step on | each other’s toes). | | | | > Since in the first round the possible list of extensions may be quite | > big, we might introduce a "fast-lane process" for this one time, for | > extensions like EmptyDataDecls or different number formats which seem | > to have unanimous support. | | I guess I agree, and I’d just make that the only process :-) | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d8096 | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd0 | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516 | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL | QKwKyWug5dv9Y5coJcQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

9:33 a.m.

New subject: GHC 2020

Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough If we are conducting a poll, we could poll for that too. So the questions could be 1. Should we have a GHCxxx mechanism at all? (Point to rationale.) (yes: definitely … no: counterproductive) Give reasons for your response (open text box); including whether this is your personal opinion, or whether you are speaking for a company that uses Haskell in production 2. If we had such a mechanism, how often should we run it? (1,2,3, yrs) Give reasons… 3. If we had GHC 2020, which extensions should be in it (offer a radio-button list of the plausible candidates) Simon From: Alejandro Serrano Mena Sent: 19 October 2020 14:22 To: Simon Peyton Jones Cc: Joachim Breitner ; ghc-steering-committee@haskell.org Subject: Re: [ghc-steering-committee] GHC 2020 Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on. I like Joachim's proposal, if you all agree that pushing this from the Committee would be well-received by the community. I would prefer to have a single PR coming from the community, maybe integrating that proposal with a few points in which we gather input from the community. Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years. Regards, Alejandro El lun., 19 oct. 2020 a las 9:22, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió: Some thoughts * I'm willing, but not truly enthusiastic, about the whole idea. The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll. * Do we really want to an annual process? My personal thought is that every two or three years would be plenty often enough. Having a plethora of extensions is confusing. "Is Polykinds in GHC2023?" * When it comes to individual extensions, I'd like to know what the community thinks, since a lot of this is about convenience and stability. I'd suggest a poll of Haskell users. Their votes might guide the committee -- but would not determine the outcome. * I would also suggest that the process be informed by a trawl of Hackage/Stackage to count how widely used each extension is. That is, seek data as well as opinion. * Joachim's 2/3 supermajority seems sensible. An extension should only make it in if there is solid support. Simon | -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Joachim Breitner | Sent: 18 October 2020 22:01 | To: ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena: | > I would really like this effort not to die, so I've given the | > proposal another push. Following the comments from Simon and Joachim, | > I've re-framed the proposal as laying down a process to create new | > "language versions" yearly. The idea is to have one of these every | > year (or 2, or 3, whatever is decided), coinciding with the spring | > release of GHC. | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fb.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337584006%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=s0taahypx2%2ByOvZRKv3mhtRYu9sp3zaabVepjxLL23g%3D&reserved=0%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000- | ghc- | 2020.md&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337593959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F7JKxag0Ka7JApEnxz%2BF4CCF8snNy8yknDsy68Q4sLM%3D&reserved=0%7Cbdddd9d809644bd069 | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681 | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg | pFwJB8wvBxWULqIqFes%3D&reserved=0 | | | I like the idea of tying this to the Spring release of GHC, this | provides a lot of predictability, and also provides a hard deadline, | which makes it more likely to make _some_ progress (instead of never | achieving the perfect set of extensions). | | To questions about the criteria: | | | If GHC2021 contains extension Foo, I assume that by default, GHC2020 | also contains Foo. But should we allow ourselves to remove something? | (I would argue, yes: it should be a rare thing, but if Foo turned out | to be problematic, then it seems better to not include it in the next | version. Code that still declares 2021 wouldn’t be affected, and code | that wants to use GHC2021 and Foo would have to list Foo explicitly, | which is arguably a good thing.) | | | Should we make it a hard rule that the extension needs to be supported | by the last _n_ versions of GHC? | (Would we maybe make point releases of prior versions of GHC to | understand -XGHC2021, to make these sets of extensions available to | more users faster?) | | | > I think it's important for the community to be involved in the | > process. If it's clear that an extension is loved by most of the | > community, that's a big plus for acceptance. In addition, if we come | > with a list ourselves, we risk having made choices which only show | > our (biased) point of view. | | I would hope that with 10 people on the committee, the bias is not too | big. And just like GHC proposals that attract discussions are sent back | as “needs review”, extensions that cause non-trivial discussion are, by | definition, not uncontroversial enough, and should simply be “maybe | next year”. | | Therefore I would like to start with a slimmer, more effective and | efficient process that does not involve a full proposal-size discussion | on each extension, and does _not_ cause dozends of parallel discussions | with the community. So here is a first draft of the “slim proceess”: | | ============================================================= | | * 4 months before the expected GHC spring release day of 202x: | The Secretary starts the GHC202x process. with an email to the list | listing all language extensions supported by GHC that are not in | GHC202(x-1), and asking the committee for “votes” (which are also | nominations). | | The secretary also creates a PR with a proposal saying (roughly) | > GHC202x contains the following extensions in addition to those | > in GHC202(x-1): | > | > * (none yet) | | The community may use comments on this PR to weigh in. | | * Within two weeks of the start of the process, | every committee member is expected to send an | initial list of which extensions they expect to be in GHC202x | to the mailing list. These mails may contain justifications | for why a certain extension is or is not included. | | After these two weeks, the PR is continuously updated by the | secretary to reflect the _current_ tally of votes: | An extension is included if it is listed by at least ⅔ (rounded up) | of committee members. | | * Within four weeks, of the start of the process, | committee members can change their vote (by email to the list). | | It is absolutely ok to change your mind based on the explanations in | the other members’ emails, or the general comments on the PR. | | * After these four weeks, the proposal with the current tally | gets accepted, and defines GHC202x | | ============================================================= | | The goal here is, of course, to efficiently find out which are the | uncontentious extensions, without spending a log of time on the | contentious ones (which I think we simply want to continue to guard | behind their own explicit extension). | | | Meta-process comments: | I’ll turn this into an alternative PR to Alejandro’s once he opened | his, and we can vote on both together (using ordered voting, I still | prefer Alejandro’s process to no GHC2021, this way we don’t step on | each other’s toes). | | | | > Since in the first round the possible list of extensions may be quite | > big, we might introduce a "fast-lane process" for this one time, for | > extensions like EmptyDataDecls or different number formats which seem | > to have unanimous support. | | I guess I agree, and I’d just make that the only process :-) | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.demailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.dehttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337593959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B46NEAsMyMKCVVFIPYXoD2aqdUpqEGDAZaQEgt5BFq0%3D&reserved=0%2F&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337593959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F7JKxag0Ka7JApEnxz%2BF4CCF8snNy8yknDsy68Q4sLM%3D&reserved=0%7Cbdddd9d8096 | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337603929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=sJW0g3fHOQP5gAviIGqKwcqeEm4kRb9prY%2FaAtY%2Fe5s%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337603929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Io3duR%2BSP1Fo67RE0CDxM%2FQZ9UBEhVS4%2Fde6wjtn5mY%3D&reserved=0%7Cbdddd9d809644bd0 | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516 | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL | QKwKyWug5dv9Y5coJcQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337603929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=kYiPR3cm4MbymK3eQiMMyVh95o87b%2Bin0Tb1G5yRIFI%3D&reserved=0

Joachim Breitner

9:43 a.m.

New subject: GHC 2020

Hi, Am Montag, den 19.10.2020, 13:33 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough

If we are conducting a poll, we could poll for that too.

guess I was too fast, just started a poll on reddit before seeing your message, with essentially only

...

1. Should we have a GHCxxx mechanism at all? (Point to rationale.) (yes: definitely … no: counterproductive) Give reasons for your response (open text box); including whether this is your personal opinion, or whether you are speaking for a company that uses Haskell in production

and not the others. But this is really just a quick vote to guage interest, not Google Forms-style poll to get actual feedback; guess we can do that once we got people excited.

...

2. If we had such a mechanism, how often should we run it? (1,2,3, yrs) Give reasons…

Do we really need to know that now? Why not create the first one, let people use it, and then poll “do you want the next revision soon or not so soon”?

...

3. If we had GHC 2020, which extensions should be in it (offer a radio-button list of the plausible candidates)

I’d hold that polling back until we have decided * We want do to GHC2021 * Have a process in place * Such a community vote has a place in the process Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

9:40 a.m.

New subject: GHC 2020

Hi,

...

The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

Well, let’s see :-) https://www.reddit.com/r/haskell/comments/je1t82/does_the_idea_of_xghc2021_e... Am Montag, den 19.10.2020, 15:21 +0200 schrieb Alejandro Serrano Mena:

...

Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on.

I was pondering both a pool, and gathering statistics. I like to keep things lean, but it doesn’t hurt. And I think it is compatible with the process that I proposed: Of course we can put out such a poll at appropriate time, and let the community vote, and let every committee member take the outcome of that vote into account. I would prefer to _not_ make it a formal requirement (e.g. “at least 80% in the popular vote”), if only to avoid the discussion of how reliable online votes are. As for hackage statistics, I also think that gathering that data is useful. I don't actually think widespread use is such an important criteria, if an extension is either very narrow in the target audience, or is safe and convenient, but often not worth bothering writing out the {-# LANGUAGE … #-}. For example NumericUnderscores – a nice feature if you can use it without an explicit langauge extension, and lowering the barrier to the use of such polish is (I believe) one aim of GHC202x. But then expecting widespread use of the extension seems to be self-contradictory. So yes: Let us collect these stats, and let us take them into account. Let’s not make it a formal requirement, and an informal requirement only as “please take into account” (and then I can say that NumericUnderscores, for me, does not require a huge up-take before I would vote it in.)

...

Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years.

Right, let’s _not_ argue too much about the cadence at this point. Let’s do the first one, and revisit again next summer, and maybe also listen to how it was received. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

26 Oct 26 Oct

11:37 a.m.

New subject: GHC 2020

Hi, Am Montag, den 19.10.2020, 15:40 +0200 schrieb Joachim Breitner:

...

Hi,

...
The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

Well, let’s see :-) https://www.reddit.com/r/haskell/comments/je1t82/does_the_idea_of_xghc2021_e...

a week later, we have 862 votes 655 76.0% 🤩 Oh yes yes, please! I’m so eager to use that! 127 14.7% 🙂 Sounds good I guess? I won’t use it myself, but still a good idea. 65 7.5% 🤷 Shrug, I woudn’t care. 15 1.7% 🤮 Please no, this is a horrible idea! I think that counts as a community mandate. Do any of you want to weigh in more on the formulation of criteria and process at https://github.com/ghc-proposals/ghc-proposals/pull/372? Note in particular this line – that was the idea, wasn't it? When ghc is used without an explicit language choice, the latest GHC20xx known to GHC is used. This applies in particular to uses of ghci. If no discussion arises, I’ll formally submit this soon. Is the usual “looks like nobody complains so we have consensus” enough, or do we want a proper vote on this? Note that this doesn't really set anything in stone, and we can fine-tune the process as we go. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Joachim Breitner

12:32 p.m.

New subject: GHC 2020

Hi, Am Montag, den 26.10.2020, 16:37 +0100 schrieb Joachim Breitner:

...

Hi,

Am Montag, den 19.10.2020, 15:40 +0200 schrieb Joachim Breitner:

...
Hi,

...
The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

Well, let’s see :-) https://www.reddit.com/r/haskell/comments/je1t82/does_the_idea_of_xghc2021_e...

the Haskell Weekly News podcast has a whole episode on this, and also the GHC Steering Committee in general: https://haskellweekly.news/episode/28.html It’s interesting to see how things are perceived by the community (mostly correct and as intended and expected, though :-)) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Peyton Jones

27 Oct 27 Oct

6:29 a.m.

New subject: GHC 2020

| If no discussion arises, I’ll formally submit this soon. Sounds fine to me. Thank Joachim. Simon | -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 26 October 2020 15:37 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Montag, den 19.10.2020, 15:40 +0200 schrieb Joachim Breitner: | > Hi, | > | > > The reason I'm willing is because I believe that the community | really | > > wants it -- but I'd love to have evidence for that belief. This | > > discussion is taking place on the GHC committee mailing list to | which | > > the community more broadly can't easily contribute. I'd love to | ask | > > them more explicitly, or even take a poll. | > | > Well, let’s see :-) | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | reddit.com%2Fr%2Fhaskell%2Fcomments%2Fje1t82%2Fdoes_the_idea_of_xghc20 | 21_excite_you%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47b | af714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C | 637393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo | iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VWt1s7T8wi3mB | mGLrOASPgOcQUhu003uPI9Juet0aTc%3D&reserved=0 | | a week later, we have | | 862 votes | 655 76.0% 🤩 Oh yes yes, please! I’m so eager to use that! | 127 14.7% 🙂 Sounds good I guess? I won’t use it myself, but still a | good idea. | 65 7.5% 🤷 Shrug, I woudn’t care. | 15 1.7% 🤮 Please no, this is a horrible idea! | | I think that counts as a community mandate. | | | Do any of you want to weigh in more on the formulation of criteria and | process at | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fpull%2F372&data=04%7C01%7Csimonpj%40microsoft.com%7Cca | e6b47baf714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SvTGu1w | l%2BC8OiwXEq0YrSZM8hjTxCq79obE%2FN73mBSo%3D&reserved=0? | | Note in particular this line – that was the idea, wasn't it? | | When ghc is used without an explicit language choice, the latest | GHC20xx known to GHC is used. This applies in particular to uses of | ghci. | | | If no discussion arises, I’ll formally submit this soon. Is the usual | “looks like nobody complains so we have consensus” enough, or do we | want a proper vote on this? Note that this doesn't really set anything | in stone, and we can fine-tune the process as we go. | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47baf | 714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BPpXK%2F0rHIbhj | t0xta2Ptjoc9t6fGWHhoopy0qQxqPU%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47baf714d1 | a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373932 | 34539004692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VOBV5UDa1qqQN%2BtZgj | ZfnsfO%2FLX42ij1AW09DpCqs0o%3D&reserved=0

Richard Eisenberg

19 Oct 19 Oct

10:07 a.m.

New subject: GHC 2020

Thanks for pushing this conversation along! * Though I know I may live to regret it, I think this is a good thing for GHC and for Haskell. My sense (not backed by any real research, of course) is that the community equates (perhaps subconsciously) "this file needs a lot of extensions" with "the code in this file is complicated" -- and thus can conclude that Haskell is a complicated language. This effort helps to reduce this source of negative feelings. * I prefer not doing this yearly. My vote would be for every 3 years -- but I still prefer doing it yearly over never. * Polling and data would be fantastic. We can scrape Hackage now, but polling is a function we struggle with. * I'd like to propose a middle ground between Alejandro's and Joachim's meta-proposals -- mostly because I want more community involvement and ownership than I think Joachim's proposal would allow (my proposal points begin with +; an initial * denotes that we're back to points in this email): + Use Alejandro's criteria. (This wasn't stated in Joachim's proposal, but I assume it's true there, too.) + From Alejandro: Create a new repo ghc-proposals/ghc-language. + From Joachim's proposal: 4 months before the expected GHC spring release day of 202x: The Secretary starts the GHC202x process. with an email to the list listing all language extensions supported by GHC that are not in GHC202(x-1), and asking the committee for “votes” (which are also nominations). + Within two weeks of the start of the process, every committee member is expected to send an initial list of which extensions they expect to be added to GHC20xx to the mailing list. There would *not* be justifications or motivations, just a list. + After these two weeks, the Secretary creates a new branch in the ghc-proposals/ghc-language repo, adding a new top-level file named ghc20xx.md (where xx has been instantiated appropriately). This file would contain a list of all the extensions receiving at least 2/3 (rounded up) of the responding members of the committee. (Footnote: I would love to say 2/3 of the committee membership, but history shows that not every committee member will speak up.) + The Secretary would then create a PR in ghc-proposals/ghc-language to merge the branch. This PR would state loudly not to comment on individual extensions in the PR. + Members of the community would then have 4 weeks to open Issues in the ghc-language repo to discuss individual extensions. Issue titles are required to include the extension name. When conversation reaches general consensus, the Issue would be closed, but memorialized in the ghc20xx.md file with a link to the discussion. If the discussion suggests that an extension *not* be included, that is still memorialized in the file, in a separate section of proposed-but-rejected extensions. (In this paragraph, "general consensus" does not mean unanimity, but a clear preponderance of opinion in one direction.) + After four weeks, any extensions still under broad debate would be rejected for inclusion as controversial. The Secretary would move these to the "rejected" section of the .md file with a link to the debate. Debates are encouraged to continue, with the expectation that the resolution of the debate would inform the next GHC20xx process. + The Secretary then merges the branch into the ghc-language repo, and the new language is implemented. + After another 2 months, any remaining open Issues in the repo are closed, for cleanliness. * This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's. * Meta-meta-proposal: Instead of creating competing PRs between these meta-proposals, I propose creating one PR with multiple proposals contained within one file. We can put this in a branch in the main repo (as opposed to the usual habit of putting PRs in a branch on a fork). We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs. Richard

...

On Oct 19, 2020, at 9:21 AM, Alejandro Serrano Mena wrote:

Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on.

I like Joachim's proposal, if you all agree that pushing this from the Committee would be well-received by the community. I would prefer to have a single PR coming from the community, maybe integrating that proposal with a few points in which we gather input from the community.

Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years.

Regards, Alejandro

El lun., 19 oct. 2020 a las 9:22, Simon Peyton Jones via ghc-steering-committee (mailto:ghc-steering-committee@haskell.org>) escribió: Some thoughts

* I'm willing, but not truly enthusiastic, about the whole idea. The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

* Do we really want to an annual process? My personal thought is that every two or three years would be plenty often enough. Having a plethora of extensions is confusing. "Is Polykinds in GHC2023?"

* When it comes to individual extensions, I'd like to know what the community thinks, since a lot of this is about convenience and stability. I'd suggest a poll of Haskell users. Their votes might guide the committee -- but would not determine the outcome.

* I would also suggest that the process be informed by a trawl of Hackage/Stackage to count how widely used each extension is. That is, seek data as well as opinion.

* Joachim's 2/3 supermajority seems sensible. An extension should only make it in if there is solid support.

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:bounces@haskell.org> On Behalf Of Joachim Breitner | Sent: 18 October 2020 22:01 | To: ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena: | > I would really like this effort not to die, so I've given the | > proposal another push. Following the comments from Simon and Joachim, | > I've re-framed the proposal as laying down a process to create new | > "language versions" yearly. The idea is to have one of these every | > year (or 2, or 3, whatever is decided), coinciding with the spring | > release of GHC. | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com http://b.com/%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000- | ghc- | 2020.md&data=04%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7Cbdddd9d809644bd069 | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681 | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg | pFwJB8wvBxWULqIqFes%3D&reserved=0 | | | I like the idea of tying this to the Spring release of GHC, this | provides a lot of predictability, and also provides a hard deadline, | which makes it more likely to make _some_ progress (instead of never | achieving the perfect set of extensions). | | To questions about the criteria: | | | If GHC2021 contains extension Foo, I assume that by default, GHC2020 | also contains Foo. But should we allow ourselves to remove something? | (I would argue, yes: it should be a rare thing, but if Foo turned out | to be problematic, then it seems better to not include it in the next | version. Code that still declares 2021 wouldn’t be affected, and code | that wants to use GHC2021 and Foo would have to list Foo explicitly, | which is arguably a good thing.) | | | Should we make it a hard rule that the extension needs to be supported | by the last _n_ versions of GHC? | (Would we maybe make point releases of prior versions of GHC to | understand -XGHC2021, to make these sets of extensions available to | more users faster?) | | | > I think it's important for the community to be involved in the | > process. If it's clear that an extension is loved by most of the | > community, that's a big plus for acceptance. In addition, if we come | > with a list ourselves, we risk having made choices which only show | > our (biased) point of view. | | I would hope that with 10 people on the committee, the bias is not too | big. And just like GHC proposals that attract discussions are sent back | as “needs review”, extensions that cause non-trivial discussion are, by | definition, not uncontroversial enough, and should simply be “maybe | next year”. | | Therefore I would like to start with a slimmer, more effective and | efficient process that does not involve a full proposal-size discussion | on each extension, and does _not_ cause dozends of parallel discussions | with the community. So here is a first draft of the “slim proceess”: | | ============================================================= | | * 4 months before the expected GHC spring release day of 202x: | The Secretary starts the GHC202x process. with an email to the list | listing all language extensions supported by GHC that are not in | GHC202(x-1), and asking the committee for “votes” (which are also | nominations). | | The secretary also creates a PR with a proposal saying (roughly) | > GHC202x contains the following extensions in addition to those | > in GHC202(x-1): | > | > * (none yet) | | The community may use comments on this PR to weigh in. | | * Within two weeks of the start of the process, | every committee member is expected to send an | initial list of which extensions they expect to be in GHC202x | to the mailing list. These mails may contain justifications | for why a certain extension is or is not included. | | After these two weeks, the PR is continuously updated by the | secretary to reflect the _current_ tally of votes: | An extension is included if it is listed by at least ⅔ (rounded up) | of committee members. | | * Within four weeks, of the start of the process, | committee members can change their vote (by email to the list). | | It is absolutely ok to change your mind based on the explanations in | the other members’ emails, or the general comments on the PR. | | * After these four weeks, the proposal with the current tally | gets accepted, and defines GHC202x | | ============================================================= | | The goal here is, of course, to efficiently find out which are the | uncontentious extensions, without spending a log of time on the | contentious ones (which I think we simply want to continue to guard | behind their own explicit extension). | | | Meta-process comments: | I’ll turn this into an alternative PR to Alejandro’s once he opened | his, and we can vote on both together (using ordered voting, I still | prefer Alejandro’s process to no GHC2021, this way we don’t step on | each other’s toes). | | | | > Since in the first round the possible list of extensions may be quite | > big, we might introduce a "fast-lane process" for this one time, for | > extensions like EmptyDataDecls or different number formats which seem | > to have unanimous support. | | I guess I agree, and I’d just make that the only process :-) | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de mailto:mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de http://breitner.de/%2F&data=04%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7Cbdddd9d8096 | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail. | haskell.org http://haskell.org/%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com http://40microsoft.com/%7Cbdddd9d809644bd0 | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516 | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL | QKwKyWug5dv9Y5coJcQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Alejandro Serrano Mena

10:16 a.m.

New subject: GHC 2020

We have 50 answers in just 30 minutes :O El lun., 19 oct. 2020 a las 16:07, Richard Eisenberg () escribió:

...

Thanks for pushing this conversation along!

* Though I know I may live to regret it, I think this is a good thing for GHC and for Haskell. My sense (not backed by any real research, of course) is that the community equates (perhaps subconsciously) "this file needs a lot of extensions" with "the code in this file is complicated" -- and thus can conclude that Haskell is a complicated language. This effort helps to reduce this source of negative feelings.

* I prefer not doing this yearly. My vote would be for every 3 years -- but I still prefer doing it yearly over never.

* Polling and data would be fantastic. We can scrape Hackage now, but polling is a function we struggle with.

* I'd like to propose a middle ground between Alejandro's and Joachim's meta-proposals -- mostly because I want more community involvement and ownership than I think Joachim's proposal would allow (my proposal points begin with +; an initial * denotes that we're back to points in this email):

+ Use Alejandro's criteria. (This wasn't stated in Joachim's proposal, but I assume it's true there, too.)

+ From Alejandro: Create a new repo ghc-proposals/ghc-language.

+ From Joachim's proposal: 4 months before the expected GHC spring release day of 202x: The Secretary starts the GHC202x process. with an email to the list listing all language extensions supported by GHC that are not in GHC202(x-1), and asking the committee for “votes” (which are also nominations).

+ Within two weeks of the start of the process, every committee member is expected to send an initial list of which extensions they expect to be added to GHC20xx to the mailing list. There would *not* be justifications or motivations, just a list.

+ After these two weeks, the Secretary creates a new branch in the ghc-proposals/ghc-language repo, adding a new top-level file named ghc20xx.md (where xx has been instantiated appropriately). This file would contain a list of all the extensions receiving at least 2/3 (rounded up) of the responding members of the committee. (Footnote: I would love to say 2/3 of the committee membership, but history shows that not every committee member will speak up.)

+ The Secretary would then create a PR in ghc-proposals/ghc-language to merge the branch. This PR would state loudly not to comment on individual extensions in the PR.

+ Members of the community would then have 4 weeks to open Issues in the ghc-language repo to discuss individual extensions. Issue titles are required to include the extension name. When conversation reaches general consensus, the Issue would be closed, but memorialized in the ghc20xx.md file with a link to the discussion. If the discussion suggests that an extension *not* be included, that is still memorialized in the file, in a separate section of proposed-but-rejected extensions. (In this paragraph, "general consensus" does not mean unanimity, but a clear preponderance of opinion in one direction.)

+ After four weeks, any extensions still under broad debate would be rejected for inclusion as controversial. The Secretary would move these to the "rejected" section of the .md file with a link to the debate. Debates are encouraged to continue, with the expectation that the resolution of the debate would inform the next GHC20xx process.

+ The Secretary then merges the branch into the ghc-language repo, and the new language is implemented.

+ After another 2 months, any remaining open Issues in the repo are closed, for cleanliness.

* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.

* Meta-meta-proposal: Instead of creating competing PRs between these meta-proposals, I propose creating one PR with multiple proposals contained within one file. We can put this in a branch in the main repo (as opposed to the usual habit of putting PRs in a branch on a fork). We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.

Richard

On Oct 19, 2020, at 9:21 AM, Alejandro Serrano Mena wrote:

Following Simon's ideas, should we maybe create a poll and some scripts to scrape Hackage/Stackage and inform our decision? For the poll I'm thinking on something like categorizing how much people "want" an extension to be on automatically, ranging from "yes, please!" to "never!". We could even gather a few more opinions about why the choice was made and selecting things like "stability" and so on.

I like Joachim's proposal, if you all agree that pushing this from the Committee would be well-received by the community. I would prefer to have a single PR coming from the community, maybe integrating that proposal with a few points in which we gather input from the community.

Finally, I'm not at all tied to having a yearly process. If you think 2 or 3 years would be enough, that's 100% fine with me. In fact, my focus is to get the first GHC2020 out. But I think that telling people that there are new chances in a definite period of time helps in giving a mid-term perspective: we don't have to have the perfect set now, we can start and keep refining in the upcoming years.

Regards, Alejandro

El lun., 19 oct. 2020 a las 9:22, Simon Peyton Jones via ghc-steering-committee () escribió:

...
Some thoughts

* I'm willing, but not truly enthusiastic, about the whole idea. The reason I'm willing is because I believe that the community really wants it -- but I'd love to have evidence for that belief. This discussion is taking place on the GHC committee mailing list to which the community more broadly can't easily contribute. I'd love to ask them more explicitly, or even take a poll.

* Do we really want to an annual process? My personal thought is that every two or three years would be plenty often enough. Having a plethora of extensions is confusing. "Is Polykinds in GHC2023?"

* When it comes to individual extensions, I'd like to know what the community thinks, since a lot of this is about convenience and stability. I'd suggest a poll of Haskell users. Their votes might guide the committee -- but would not determine the outcome.

* I would also suggest that the process be informed by a trawl of Hackage/Stackage to count how widely used each extension is. That is, seek data as well as opinion.

* Joachim's 2/3 supermajority seems sensible. An extension should only make it in if there is solid support.

Simon

| -----Original Message----- | From: ghc-steering-committee On Behalf Of Joachim Breitner | Sent: 18 October 2020 22:01 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] GHC 2020 | | Hi, | | Am Samstag, den 17.10.2020, 21:26 +0200 schrieb Alejandro Serrano Mena: | > I would really like this effort not to die, so I've given the | > proposal another push. Following the comments from Simon and Joachim, | > I've re-framed the proposal as laying down a process to create new | > "language versions" yearly. The idea is to have one of these every | > year (or 2, or 3, whatever is decided), coinciding with the spring | > release of GHC. | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu | b.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000- | ghc- | 2020.md&data=04%7C01%7Csimonpj%40microsoft.com %7Cbdddd9d809644bd069 | 9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681 | 5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ | BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg | pFwJB8wvBxWULqIqFes%3D&reserved=0 | | | I like the idea of tying this to the Spring release of GHC, this | provides a lot of predictability, and also provides a hard deadline, | which makes it more likely to make _some_ progress (instead of never | achieving the perfect set of extensions). | | To questions about the criteria: | | | If GHC2021 contains extension Foo, I assume that by default, GHC2020 | also contains Foo. But should we allow ourselves to remove something? | (I would argue, yes: it should be a rare thing, but if Foo turned out | to be problematic, then it seems better to not include it in the next | version. Code that still declares 2021 wouldn’t be affected, and code | that wants to use GHC2021 and Foo would have to list Foo explicitly, | which is arguably a good thing.) | | | Should we make it a hard rule that the extension needs to be supported | by the last _n_ versions of GHC? | (Would we maybe make point releases of prior versions of GHC to | understand -XGHC2021, to make these sets of extensions available to | more users faster?) | | | > I think it's important for the community to be involved in the | > process. If it's clear that an extension is loved by most of the | > community, that's a big plus for acceptance. In addition, if we come | > with a list ourselves, we risk having made choices which only show | > our (biased) point of view. | | I would hope that with 10 people on the committee, the bias is not too | big. And just like GHC proposals that attract discussions are sent back | as “needs review”, extensions that cause non-trivial discussion are, by | definition, not uncontroversial enough, and should simply be “maybe | next year”. | | Therefore I would like to start with a slimmer, more effective and | efficient process that does not involve a full proposal-size discussion | on each extension, and does _not_ cause dozends of parallel discussions | with the community. So here is a first draft of the “slim proceess”: | | ============================================================= | | * 4 months before the expected GHC spring release day of 202x: | The Secretary starts the GHC202x process. with an email to the list | listing all language extensions supported by GHC that are not in | GHC202(x-1), and asking the committee for “votes” (which are also | nominations). | | The secretary also creates a PR with a proposal saying (roughly) | > GHC202x contains the following extensions in addition to those | > in GHC202(x-1): | > | > * (none yet) | | The community may use comments on this PR to weigh in. | | * Within two weeks of the start of the process, | every committee member is expected to send an | initial list of which extensions they expect to be in GHC202x | to the mailing list. These mails may contain justifications | for why a certain extension is or is not included. | | After these two weeks, the PR is continuously updated by the | secretary to reflect the _current_ tally of votes: | An extension is included if it is listed by at least ⅔ (rounded up) | of committee members. | | * Within four weeks, of the start of the process, | committee members can change their vote (by email to the list). | | It is absolutely ok to change your mind based on the explanations in | the other members’ emails, or the general comments on the PR. | | * After these four weeks, the proposal with the current tally | gets accepted, and defines GHC202x | | ============================================================= | | The goal here is, of course, to efficiently find out which are the | uncontentious extensions, without spending a log of time on the | contentious ones (which I think we simply want to continue to guard | behind their own explicit extension). | | | Meta-process comments: | I’ll turn this into an alternative PR to Alejandro’s once he opened | his, and we can vote on both together (using ordered voting, I still | prefer Alejandro’s process to no GHC2021, this way we don’t step on | each other’s toes). | | | | > Since in the first round the possible list of extensions may be quite | > big, we might introduce a "fast-lane process" for this one time, for | > extensions like EmptyDataDecls or different number formats which seem | > to have unanimous support. | | I guess I agree, and I’d just make that the only process :-) | | Cheers, | Joachim | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo | achim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com %7Cbdddd9d8096 | 44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373 | 86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu | MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3csJZH2Ux30FM4OIpLb | QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail . | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com %7Cbdddd9d809644bd0 | 699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516 | 815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL | CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=SpEo1OwwBHDb7uIlkgBrnKbL | QKwKyWug5dv9Y5coJcQ%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

11:05 a.m.

New subject: GHC 2020

Hi, Am Montag, den 19.10.2020, 14:07 +0000 schrieb Richard Eisenberg:

...

* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.

My proposal is mis-phrased: I suggest _not_ debating. I want GHC2021 to contain only uncontroversial extensions. If debating flares up about a specific extension, that’s already a clear sign that the extension should not make it _this round_, which settles that very discussion. If at any point a committee member feels like strongly arguing in favor of an extension that does not already have a majority with more emphasis than just “here are some good points you might have missed”, then such an extension is not uncontroversial, and would simply be voted out. I expect us from refraining from strongly and verbosely arguing for an individual extension, and thus no discussion ensues. If at any point a committee member feels like strongly arguing against an extension that does already have a majority, then I expect that at least three other members will take that as “clearly not uncontroversial”, remove it from their vote, and make any further discussion not needed. I think it is wrong to think the decision “Should Foo be part of GHC20201” needs the same level of rigor as “should Foo exist”. In the latter case, if we say no, somebody is unhappy because they can’t use a feature they care about. So we really need the detailed discussion, and refinement etc. So yay for PRs. In the former case, if we say no, it’s no big deal, people will have to continue saying {-# LANGUAGE Foo #-} for a few more years. This does not hurt anyone! And therefore, I strongly advise against any heavy per-extension discussion process.

...

We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.

That’s a good point; we can have options in one PR and still do ranked voting. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Alejandro Serrano Mena

3:24 p.m.

New subject: GHC 2020

It seems that people like the idea, 300 out of 400 respondents gave a "yes!", with around 100 saying it's a good idea or not caring. If we did some meta-PR, I would prefer to simply discuss Joachim's and Richard's proposals. I've been convinced that discussing per-extension would result in endless pain, and I am in favour of making the Committee "seed" the process with the list of extensions. Any other source of information (polls, stats) should be considered, but I agree with Joachim that some extensions may not be used that much, but pose a very low barrier, and thus should be accepted. I don't think that would be a problem, I trust ourselves not making crazy decisions. What do the rest of the Committee think? Alejandro El lun., 19 oct. 2020 a las 17:05, Joachim Breitner (< mail@joachim-breitner.de>) escribió:

...

Hi,

Am Montag, den 19.10.2020, 14:07 +0000 schrieb Richard Eisenberg:

...
* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.

My proposal is mis-phrased: I suggest _not_ debating. I want GHC2021 to contain only uncontroversial extensions. If debating flares up about a specific extension, that’s already a clear sign that the extension should not make it _this round_, which settles that very discussion.

If at any point a committee member feels like strongly arguing in favor of an extension that does not already have a majority with more emphasis than just “here are some good points you might have missed”, then such an extension is not uncontroversial, and would simply be voted out. I expect us from refraining from strongly and verbosely arguing for an individual extension, and thus no discussion ensues.

If at any point a committee member feels like strongly arguing against an extension that does already have a majority, then I expect that at least three other members will take that as “clearly not uncontroversial”, remove it from their vote, and make any further discussion not needed.

I think it is wrong to think the decision “Should Foo be part of GHC20201” needs the same level of rigor as “should Foo exist”.

In the latter case, if we say no, somebody is unhappy because they can’t use a feature they care about. So we really need the detailed discussion, and refinement etc. So yay for PRs.

In the former case, if we say no, it’s no big deal, people will have to continue saying {-# LANGUAGE Foo #-} for a few more years. This does not hurt anyone!

And therefore, I strongly advise against any heavy per-extension discussion process.

...
We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.

That’s a good point; we can have options in one PR and still do ranked voting.

Cheers, Joachim

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Simon Peyton Jones

20 Oct 20 Oct

3:23 a.m.

New subject: GHC 2020

I’m fine with agreeing a process. I do think we should consult the community (via a poll) about which extensions to include, and Hackage about which extensions are used. But still make decisions ourselves (informed by the community input). Simon From: ghc-steering-committee On Behalf Of Alejandro Serrano Mena Sent: 19 October 2020 20:24 To: Joachim Breitner Cc: ghc-steering-committee Subject: Re: [ghc-steering-committee] GHC 2020 It seems that people like the idea, 300 out of 400 respondents gave a "yes!", with around 100 saying it's a good idea or not caring. If we did some meta-PR, I would prefer to simply discuss Joachim's and Richard's proposals. I've been convinced that discussing per-extension would result in endless pain, and I am in favour of making the Committee "seed" the process with the list of extensions. Any other source of information (polls, stats) should be considered, but I agree with Joachim that some extensions may not be used that much, but pose a very low barrier, and thus should be accepted. I don't think that would be a problem, I trust ourselves not making crazy decisions. What do the rest of the Committee think? Alejandro El lun., 19 oct. 2020 a las 17:05, Joachim Breitner (mailto:mail@joachim-breitner.de>) escribió: Hi, Am Montag, den 19.10.2020, 14:07 +0000 schrieb Richard Eisenberg:

...

* This counter-counter-proposal is meant to combine what I see are the best qualities of both proposals: the structure in Alejandro's (Joachim's suggests just debating about extensions over email, which causes me to shudder in horror, even if the discussion is just among committee members), with the committee-seeding from Joachim's.

...

We'll all edit the meta-proposal as need-be, with the expectation that we friends do not clobber each other's work. Seems simpler than having the conversation spread among multiple PRs.

That’s a good point; we can have options in one PR and still do ranked voting. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.demailto:mail@joachim-breitner.de http://www.joachim-breitner.de/https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Ccc54e3a12f5843a64e5908d874649b76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387322741398332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ll3x7YCeK9WX9vRXhPpx1Y9MXXv9saxPOs%2F347joONM%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Ccc54e3a12f5843a64e5908d874649b76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387322741398332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yTvhE7jxAPBkmNSfXdF6KXAD8%2BQiRMDp%2B7ip9WTCTNU%3D&reserved=0

Joachim Breitner

22 Oct 22 Oct

10:07 a.m.

New subject: GHC 2020

Hi, Am Dienstag, den 20.10.2020, 07:23 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...

I’m fine with agreeing a process.

I do think we should consult the community (via a poll) about which extensions to include, and Hackage about which extensions are used. But still make decisions ourselves (informed by the community input).

I took Alejandro’s draft proposal test, added the process that I outlined, added steps for hackage stats and community polls, and put it now up for discussion at https://github.com/ghc-proposals/ghc-proposals/pull/372 Please discuss there if this needs refinement. Two open questions to be discussed (there): -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Simon Marlow

23 Oct 23 Oct

3:36 a.m.

New subject: GHC 2020

I just wanted to point out that there was a poll on which extensions people would like to have enabled by default as part of the 2019 state of Haskell survey, the results are here: https://taylor.fausak.me/2019/11/16/haskell-survey-results/#s2q5 Personally I'm not sure we need another poll. Data from actual usage (i.e. Hackage) would be more valuable I would think. Cheers Simon On Thu, 22 Oct 2020 at 15:07, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 20.10.2020, 07:23 +0000 schrieb Simon Peyton Jones via ghc-steering-committee:

...
I’m fine with agreeing a process.

I do think we should consult the community (via a poll) about which extensions to include, and Hackage about which extensions are used. But still make decisions ourselves (informed by the community input).

I took Alejandro’s draft proposal test, added the process that I outlined, added steps for hackage stats and community polls, and put it now up for discussion at https://github.com/ghc-proposals/ghc-proposals/pull/372

Please discuss there if this needs refinement.

Two open questions to be discussed (there):

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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

1666

Age (days ago)

1676

Last active (days ago)

List overview

Download

16 comments

5 participants

participants (5)

Alejandro Serrano Mena
Joachim Breitner
Richard Eisenberg
Simon Marlow
Simon Peyton Jones

Re: [ghc-steering-committee] GHC 2020

tags

participants (5)