[ghc-steering-committee] GHC 2020

Simon Marlow marlowsd at gmail.com
Thu Sep 17 14:42:17 UTC 2020


I think there should be some requirement that an extension be widely-used
(for some suitable definition of that), before we ratify it in GHC2020.
Some of the extensions that made it past the first round of filtering are
not widely-used, and would be therefore probably be controversial additions
to a language standard - e.g. ViewPatterns, ParallelListComp, RecursiveDo
to name a few that I noticed straight off. I think it's a good idea to be
conservative here.

Cheers
Simon

On Thu, 10 Sep 2020 at 10:29, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> There seems to be some question about who should drive this debate. But
> there is something we all seem to agree on: it is our role, as the steering
> committee, to announce the criteria by which we intend to judge the
> reasonableness of each potential candidate extension.
>
> So, let me suggest that we start discussing that, and move back to how
> this discussion ought to be driven when we are a bit clearer on the
> criteria.
>
> Richard wrote a bunch of criteria in the wiki page upthread [1]. I think
> that they are worthy of discussion. So let me ask the question: do we agree
> with all these criteria? do we want to add more?
>
> [1]: https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020
>
> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
>> I would rather make the process Committee-driven, because otherwise it
>> may derail into too many micro-discussions. I think it's better to start a
>> conversation saying "this is our proposal, here are our criteria, here are
>> the exceptions we want to make", and then discuss from there.
>>
>> Regards,
>> Alejandro
>>
>>
>> El mar., 8 sept. 2020 a las 14:01, Eric Seidel (<eric at seidel.io>)
>> escribió:
>>
>>> I think we may want to have the Committee initiate and drive the
>>> process. I think a GHC20XX proposal will turn into a bunch of micro
>>> proposals and discussions about individual (groups of) extensions, and it
>>> will be hard to track all of the threads of discussion in a single GitHub
>>> thread. We’ve dealt with long and contentious discussions before, but they
>>> were much more focused than GHC20XX will be, by design.
>>>
>>> I suggested earlier that an alternative strategy could be to open a new
>>> repo where the community can collaborate on GHC20XX via a familiar PR-based
>>> process, with each proposed group of extensions getting its own PR and
>>> discussion. There are a few open questions here though. When/how do we
>>> decide that it’s time for a new standard? How do we decide when the full
>>> proposal is ready for review? Do we need to review and sign off on each
>>> group of extensions separately or only the final product?
>>>
>>> This process would be a lot more work for us, so I’m happy to try the
>>> usual process first, and I’ll be happy to be proved wrong. But we should be
>>> prepared to step in and add some more structure if needed.
>>>
>>> Regardless, the first step should be to update our docs to express
>>> interest in GHC20XX proposals, establish criteria for including language
>>> extensions, and outline a process for submitting them.
>>>
>>> Eric
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 8, 2020, at 06:37, Simon Peyton Jones <simonpj at microsoft.com>
>>> wrote:
>>>
>>> 
>>>
>>> Personally I don’t think we should make the Steering Committee
>>> responsible for initiating or driving this.  We should
>>>
>>>    - establish the criteria (including some idea of how frequently we’d
>>>    be open to creating a new GHCxx version),
>>>    - express open-ness to a proposal, and then
>>>    - review proposals when/if they materialise.
>>>
>>>
>>>
>>> It’d be fine for Alejandro, as an individual, to be a proposer. But
>>> that’s different from making the committee *responsible*.
>>>
>>>
>>>
>>> What do others think?
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 08 September 2020 09:13
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Richard Eisenberg <rae at richarde.dev>; Eric Seidel <eric at seidel.io>;
>>> ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> Dear all,
>>>
>>> I would really like to move this forward, and I would be happy to put
>>> some work on it.
>>>
>>>
>>>
>>> What do you think of the following plan?
>>>
>>> - Create a ghc-proposal based on the (awesome) wiki page by Richard. I
>>> think the criteria in the wiki are quite nice. Explain that one of the
>>> goals is to encompass as many stable extensions as possible.
>>>
>>> - Reformat the list to make 3 tables: one for extensions which satisfy
>>> all 5 criteria, one for extensions we want to include even if they don't,
>>> and one for those which should be rejected in the light of those criteria.
>>>
>>>
>>>
>>> If the process works well, we could think about instaurating a
>>> yearly/bi-yearly/n-yearly process to create new -XGHC20XX versions.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandro
>>>
>>>
>>>
>>> El lun., 7 sept. 2020 a las 17:32, Simon Peyton Jones via
>>> ghc-steering-committee (<ghc-steering-committee at haskell.org>) escribió:
>>>
>>> Just back from holiday. Some thoughts
>>>
>>> * I don’t think this mailing list is the best place for the
>>>   discussion.  Basically, it's a GHC Proposal, so someone (possibly
>>>   a committee member, possibly not) should write a proposal,
>>>   and we should put it through the process.
>>>
>>> * We should advertise the criteria, as Richard has done on the
>>>   wiki page.
>>>
>>> * Any such proposal should be informed by data. Notably, extension usage
>>>   in Hackage, or perhaps Stackage (since it's a bit more curated).
>>>
>>> * A proposer might also want to run a public poll, as an additional
>>>   source of data
>>>
>>> * When it comes to the committee, we can (I guess) vote on individual
>>>   extensions, rather than just accept/reject the whole thing.
>>>
>>> I am intrigued by the idea of using Kialo to coordinate discussion.
>>> Maybe it'd work better than GitHub?  Are there other alternatives?
>>> But that's orthogonal to the GHC 2020 idea; let's not conflate them.
>>>
>>> Simon
>>>
>>> |  -----Original Message-----
>>> |  From: ghc-steering-committee <ghc-steering-committee-
>>> |  bounces at haskell.org> On Behalf Of Richard Eisenberg
>>> |  Sent: 02 September 2020 14:57
>>> |  To: Eric Seidel <eric at seidel.io>
>>> |  Cc: ghc-steering-committee at haskell.org
>>> |  Subject: Re: [ghc-steering-committee] GHC 2020
>>> |
>>> |  It seems clear that my wiki idea isn't winning the day -- I never
>>> |  really liked it either. I'd be fine with either Eric's or Joachim's
>>> |  approaches. Maybe start with Joachim's approach and then use Eric's
>>> |  when Joachim's runs out of steam? A big minus, though, to Joachim's
>>> |  approach is that it seems hard to get good community involvement.
>>> |
>>> |  Richard
>>> |
>>> |  > On Sep 2, 2020, at 8:11 AM, Eric Seidel <eric at seidel.io> wrote:
>>> |  >
>>> |  > Opening a regular discussion about whether and how we want to work
>>> on
>>> |  GHC 2020 sounds fine, that will also give the community a place to
>>> |  weigh in. I do think the eventual contents should be informed by the
>>> |  community though, it shouldn’t just be us working alone.
>>> |  >
>>> |  > Sent from my iPhone
>>> |  >
>>> |  >> On Sep 2, 2020, at 03:16, Joachim Breitner <mail at joachim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986435664&sdata=Vfd5PeSlx%2FqLuT96wFjzBj0%2FVPgXrNqH%2FMgSj8g2QiM%3D&reserved=0>>
>>> wrote:
>>> |  >>
>>> |  >> Hi,
>>> |  >>
>>> |  >> sounds plausible. It would also allow us to use tags to easily
>>> |  indicate
>>> |  >> the status (e.g. clearly-not, definitely-yes, kinda-contested…),
>>> and
>>> |  >> then filter by issue to get the current list…
>>> |  >>
>>> |  >> But before we go there, shouldn’t we maybe have a discussion first
>>> |  on
>>> |  >>
>>> |  >> * do we even want that?
>>> |  >> * what are the abstract criteria (or guidelines)?
>>> |  >> * what is the process?
>>> |  >>
>>> |  >> I believe that discussion could be done like any other proposal.
>>> |  >>
>>> |  >>
>>> |  >> As for the process; when I brought up the idea, I was worried about
>>> |  us
>>> |  >> spending huge resources discussion individual extensions to death,
>>> |  and
>>> |  >> proposed, in the interest of efficiency and getting things done:
>>> |  >>
>>> |  >>> The process could be: Every member can nominate any number of
>>> |  >>> extensions, to include, maybe a small rationale and then we do one
>>> |  >>> round of independent approval voting, requiring a supermajority to
>>> |  >>> really only pick uncontested extensions.
>>> |  >>
>>> |  >> So instead of long debates, we start with GHC2020 being just those
>>> |  >> extensions that a supermajority on the committee considers to be
>>> ok.
>>> |  >>
>>> |  >> This is much more lightweight process that we could get done in a
>>> |  week
>>> |  >> or two (maybe using a doodle-like voting page). Maybe we would
>>> leave
>>> |  >> out one or two extension that initially people are reserved about,
>>> |  but
>>> |  >> could be swayed after lengthy discussions. But is that worth the
>>> |  >> lengthy discussion?
>>> |  >>
>>> |  >> cheers,
>>> |  >> Joachim
>>> |  >>
>>> |  >> --
>>> |  >> Joachim Breitner
>>> |  >> mail at joachim-breitner.de
>>> |  >>
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>>> |  achim-
>>> |  breitner.de
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=O%2FFcf9XZLsKRW8ESW57%2B37Rp3WNt81xKPDn25QbT5Ng%3D&reserved=0>
>>> %2F&data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986445657&sdata=d98tn5pWeuHRDUn0PvEjhkMNFvFPvhtG00K2t2m2o9Y%3D&reserved=0>
>>> %7Cfa6e3a6bcdf
>>> |
>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>> |
>>> 46518199468575&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
>>> |  &reserved=0
>>> |  >>
>>> |  >>
>>> |  >> _______________________________________________
>>> |  >> ghc-steering-committee mailing list
>>> |  >> ghc-steering-committee at haskell.org
>>> |  >>
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>> |  haskell.org
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=jxJvPglvK%2BitmPb3xLo%2F8bXb53%2BwNzdIy8dcJvG9Af8%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986455654&sdata=%2FucisRwNnqOdjz%2FSbofsoiGsZ5AqiMAEBPzJDb2cVLw%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>> |  amp;reserved=0
>>> |  >
>>> |  > _______________________________________________
>>> |  > ghc-steering-committee mailing list
>>> |  > ghc-steering-committee at haskell.org
>>> |  >
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>> |  haskell.org
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=pV4zqeHk1VUOJ46TaHvvQzvKnMzsbRytBuZNW7Gvqnw%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986465647&sdata=uAyqrWp9qv8ITFhpkFmg3C%2F%2F3yDo404jsMfqQAeIWoI%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>> |  amp;reserved=0
>>> |
>>> |  _______________________________________________
>>> |  ghc-steering-committee mailing list
>>> |  ghc-steering-committee at haskell.org
>>> |
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>> |  haskell.org
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=bBS5y5cQwD%2FlO9vxXeji9G3hgOxQD4nQLL6%2BPZartTE%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986475642&sdata=gyrumWxTU8xU70i03Ec1vsBVl%2BZeLQISVWkVT18nG7k%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>> |  amp;reserved=0
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at 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=02%7C01%7Csimonpj%40microsoft.com%7Cfaa7b2a148fd4381512c08d853cf0a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351495986485636&sdata=p07ukOVQF53cYEZwLtpOxn0l95tfeJCrF45iR0HU1mo%3D&reserved=0>
>>>
>>> _______________________________________________
>>> 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/20200917/dde60f70/attachment-0001.html>


More information about the ghc-steering-committee mailing list