[ghc-steering-committee] GHC 2020
Alejandro Serrano Mena
trupill at gmail.com
Tue Sep 29 14:50:53 UTC 2020
I am still happy to drive this! I was not sure about whether we agreed as a
Committee on pushing this.
To make this more actionable, my goal is, *during next Sunday*, to create a
new proposal with the *criteria* (based on Richard + Simon's list), and a
preliminary assessment of which of the *current extensions* satisfy these
criteria, and for those we might be willing to grant *exceptions*.
Please raise your voice if you think we should proceed otherwise (or if you
think we should not proceed at all!).
Regards,
Alejandro
El mar., 29 sept. 2020 a las 16:29, Richard Eisenberg (<rae at richarde.dev>)
escribió:
> What's the status of this push? I was delighted to see that Alejandro
> volunteered to be a motive force on this idea, and have thus refrained (as
> I am pushing on other ideas, too). But I also don't want this to die. :)
>
> Thanks!
> Richard
>
> On Sep 17, 2020, at 11:39 AM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> I agree with using the criteria that Richard posted + the addition by
> Simon. Just in case somebody hadn't looked at the wiki, the criteria would
> be:
>
> 1.
>
> The extension is (mostly) conservative: All programs that were
> accepted without the extension remain accepted, and with the same meaning.
> 2.
>
> New failure modes that become possible with the extension are rare
> and/or easy to diagnose. (These failure modes include new error messages,
> wrong inferred types, and runtime errors, for example.)
> 3.
>
> The extensions complement the design of standard Haskell. (This one
> seems the most subjective.)
> 4.
>
> The extension has been -- and can reasonably be predicted to remain --
> stable.
> 5.
>
> The extension is not to gate-keep an advanced or potentially-unsafe
> feature.
> 6. The extension is widely-used.
>
> For example, should we add to (6) "in current developments"? What about
> things like "EmptyDataDecls", which are just straightforward
> generalizations of what Haskell 2010 already allows, although in practice
> the only data type you would ever need to be empty is "Void"?
>
> Alejandro
>
> El jue., 17 sept. 2020 a las 16:42, Simon Marlow (<marlowsd at gmail.com>)
> escribió:
>
>> 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
>>>
>> _______________________________________________
> 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/20200929/b1f1b5d7/attachment-0001.html>
More information about the ghc-steering-committee
mailing list