From trupill at gmail.com  Thu Oct  1 08:02:27 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 1 Oct 2020 10:02:27 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOsFBAqS0FxgcZegv6Hc+P-1U=zH629px3xfPAQQDEn3Xg@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <CAHnFXOsFBAqS0FxgcZegv6Hc+P-1U=zH629px3xfPAQQDEn3Xg@mail.gmail.com>
Message-ID: <CAHnFXOtKrK_0VUZrHJPadT5YiiqGKzGWq=ta+SVkdb+GT_rGYA@mail.gmail.com>

I've made a decision about a few more extensions, but there are still 8
where I would really like some help:
- MagicHash: is this simply an extension or it may break code which parses
"a# b" as "a # b"?
- PartialTypeSignatures and its accompanying NamedWildCards: maybe this
should be seen more as a programmer's aid?
- PackageImports: never used it, never heard of anybody using it, so I
would say it fails criteria 6 (widespread usage)
- PostfixOperators: a deviation from the Report
- QuantifiedConstraints, RoleAnnotations: are these stable enough to be
included. I could foresee _extending_ its language, but not having to break
what's already there. But maybe they fail the widespread usage criterion?
- RecordWildCards: there was some discussion in the wiki, about possible
shadowing problems.

As it stands now, I foresee most of the discussion on:
- should GHC embrace its type level machinery? the current proposal does,
since it includes DataKinds, TypeFamilies, and so forth.
- should OverloadedLists and OverloadedStrings be part of GHC2020?
- particular choices like LambdaCase (in), BlockArguments (out),
TupleSections (out). But that's exactly what the proposal process is for!

Regards,
Alejandro

El mié., 30 sept. 2020 a las 22:12, Alejandro Serrano Mena (<
trupill at gmail.com>) escribió:

> Of course, I could also write some proposal, and then we can use the usual
> PR mechanism to discuss it.
>
> Alejandro
>
> El mié., 30 sept. 2020 a las 22:06, Alejandro Serrano Mena (<
> trupill at gmail.com>) escribió:
>
>> Dear all,
>> I've started working on a proposal for GHC2020. You can see the current
>> status here:
>> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
>>
>> I noticed the list by Richard was not exhaustive. Those extensions are
>> headed by "In discussion". Preferably we should make up our minds before
>> presenting the proposal. I would say there are three big groups of
>> proposals. Any feedback is welcome on that part.
>>
>> Regards,
>> Alejandrp
>>
>> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
>> iavor.diatchki at gmail.com>) escribió:
>>
>>> Thanks Alejandro.  My preference would be that you share whatever you
>>> come up with the list so we can discuss it, before making a proposal that
>>> would represent the committee.
>>> -Iavor
>>>
>>> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>
>>>> OK by me.   Thank you
>>>>
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>>> *From:* ghc-steering-committee <
>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>> Serrano Mena
>>>> *Sent:* 29 September 2020 15:51
>>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>>> *Cc:* ghc-steering-committee at haskell.org
>>>> *Subject:* Re: [ghc-steering-committee] GHC 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
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>
>>>>
>>>>
>>>>
>>>> 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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>
>>>> %2F&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf
>>>> |
>>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>>> |
>>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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
>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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
>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/8e909d87/attachment-0001.html>

From simonpj at microsoft.com  Thu Oct  1 08:11:24 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 1 Oct 2020 08:11:24 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
Message-ID: <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Thanks Alejandro. How do you want feedback?  The “discussed at this PR” link is broken.

I think the criteria could be tightened up quite a bit.


  *   I don’t know what “The extensions complement the design of standard Haskell” means.   What would be an example of something that doesn’t complement it?


  *   I don’t know what “The extension is not to gate-keep an advanced or potentially-unsafe feature” means.


  *   Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”.  Which is your intent?



  *   What is a “new failure mode”?  Do you mean existing programs that fail when the extension is on?  Or new programs that are trying to use the new extension but get it wrong?   For the latter it’s hard to see how they’d be rare.

Simon





From: Alejandro Serrano Mena <trupill at gmail.com>
Sent: 30 September 2020 21:06
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <rae at richarde.dev>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,
I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042159563&sdata=YwM0vlfkVllsb4lwCRydeodKqs4mAbmBnYAss7jnrXA%3D&reserved=0>

I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.

Regards,
Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>) escribió:
Thanks Alejandro.  My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee.
-Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
OK by me.   Thank you

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
Sent: 29 September 2020 15:51
To: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] GHC 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<mailto: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<mailto: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<mailto: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<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042164548&sdata=wFIQt92hr82HcXuEwTXacMF%2BEuCqyr2tnokVzqVTEQQ%3D&reserved=0>

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com<mailto: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<mailto: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<mailto: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<mailto:trupill at gmail.com>>
Sent: 08 September 2020 09:13
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>; Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org<mailto: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<mailto: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<mailto:bounces at haskell.org>> On Behalf Of Richard Eisenberg
|  Sent: 02 September 2020 14:57
|  To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
|  Cc: ghc-steering-committee at haskell.org<mailto: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<mailto: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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042169538&sdata=Ctr6M2HoRc2%2BbyWPFB4JNql2WIse14k4iWELijNVItQ%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<mailto: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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042174527&sdata=iiAtfwNwjAnv5k92F63GysP4XAvmFd9ibxIggJSisU4%3D&reserved=0>%2F&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042179516&sdata=3qCil%2FMoccFUJT5ewL2xNnAfltU6CrN4NG44tjlpv8E%3D&reserved=0>%7Cfa6e3a6bcdf
|  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
|  &amp;reserved=0
|  >>
|  >>
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org<mailto: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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042184514&sdata=fuk93MrXnqJKCb9DnER3g1PQH3CCqpxXb%2Bbd%2Fv87OjM%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042189496&sdata=FGlQfF33ahePm0M2O0zfQny8v7bAMczOIWqZyEZJyNc%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org<mailto: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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042194488&sdata=YqgMoMxpdRNYxxZN2PjexDFO%2B9Vbi8K1L%2BZ1cFhecII%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042199478&sdata=9nZFHqY8MyAbz3RWgDuYX%2B%2F2MUFkMMdFEwrFSUMmHtA%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto: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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042209458&sdata=l1fNq0SUpDnKgGJmKOea4OI69aFo7s61JUQzgU2RVSc%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042214451&sdata=JR7JtEo%2BF5akMRQtaqy4feJy%2FrtdHDoKAAOKh%2BNPmbc%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042219441&sdata=jK4hfemsYlEp5Y%2BGhWSXkte1gt9DMga8toTbWpD%2B7kc%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042224430&sdata=jV83SWi62SM15AZgduDOULnRSb55grqKOI3RzX%2BlGPE%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042229422&sdata=rOqBh76f6LeI%2F2Vz9yDjqIpu4w5dzkqOKfU7xg7REu0%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042234412&sdata=A7yxkjePHouaA880w0Z2wISl7822I42gVHE1LRzBwZE%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042239402&sdata=1HvIaICrDrNn%2Bje%2BqBDXkuNSqa9kqUZiUrtBNNoibNY%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042244393&sdata=QlkYJves2UnTUVlMabzOFybaXWJvZnxNA%2BnxcdMX1nU%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/de2d9164/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Oct  1 08:13:04 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 1 Oct 2020 10:13:04 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOtKrK_0VUZrHJPadT5YiiqGKzGWq=ta+SVkdb+GT_rGYA@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <CAHnFXOsFBAqS0FxgcZegv6Hc+P-1U=zH629px3xfPAQQDEn3Xg@mail.gmail.com>
 <CAHnFXOtKrK_0VUZrHJPadT5YiiqGKzGWq=ta+SVkdb+GT_rGYA@mail.gmail.com>
Message-ID: <CAH6fHQkSj_YDjdQjH-yLX5s2T8WH5VuUJTNBZ9ceLdX7B-UcNw@mail.gmail.com>

Some comments:

In general, I want to argue that we don't generally need all 5 criteria to
be met, it's just that violation of a criterion means arguing harder for
inclusion.

> EmptyCase: \x -> case x of {} is strict in x. This is an exception to the
general rule for case expressions, which are otherwise lazy (unless a
pattern-match forces evaluation, of course).

It's one way to look at it, certainly. But we could just as well say that
`case` is usually strict, except for variables, wildcard, and explicitly
lazy patterns. I'd guess most Haskell programmers see `case` as the
prototypical strict thing. I don't think `EmptyCase` deserves to be
considered a violation of 2 nor 3.

`AllowAmbiguousType` probably deserves a violation of criterion 2, though
(new, difficult to debug failure modes). So do `UndecidableInstance` and
`UndecidableSuperclass`.

On Thu, Oct 1, 2020 at 10:03 AM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I've made a decision about a few more extensions, but there are still 8
> where I would really like some help:
> - MagicHash: is this simply an extension or it may break code which parses
> "a# b" as "a # b"?
> - PartialTypeSignatures and its accompanying NamedWildCards: maybe this
> should be seen more as a programmer's aid?
> - PackageImports: never used it, never heard of anybody using it, so I
> would say it fails criteria 6 (widespread usage)
> - PostfixOperators: a deviation from the Report
> - QuantifiedConstraints, RoleAnnotations: are these stable enough to be
> included. I could foresee _extending_ its language, but not having to break
> what's already there. But maybe they fail the widespread usage criterion?
> - RecordWildCards: there was some discussion in the wiki, about possible
> shadowing problems.
>
> As it stands now, I foresee most of the discussion on:
> - should GHC embrace its type level machinery? the current proposal does,
> since it includes DataKinds, TypeFamilies, and so forth.
> - should OverloadedLists and OverloadedStrings be part of GHC2020?
> - particular choices like LambdaCase (in), BlockArguments (out),
> TupleSections (out). But that's exactly what the proposal process is for!
>
> Regards,
> Alejandro
>
> El mié., 30 sept. 2020 a las 22:12, Alejandro Serrano Mena (<
> trupill at gmail.com>) escribió:
>
>> Of course, I could also write some proposal, and then we can use the
>> usual PR mechanism to discuss it.
>>
>> Alejandro
>>
>> El mié., 30 sept. 2020 a las 22:06, Alejandro Serrano Mena (<
>> trupill at gmail.com>) escribió:
>>
>>> Dear all,
>>> I've started working on a proposal for GHC2020. You can see the current
>>> status here:
>>> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
>>>
>>> I noticed the list by Richard was not exhaustive. Those extensions are
>>> headed by "In discussion". Preferably we should make up our minds before
>>> presenting the proposal. I would say there are three big groups of
>>> proposals. Any feedback is welcome on that part.
>>>
>>> Regards,
>>> Alejandrp
>>>
>>> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
>>> iavor.diatchki at gmail.com>) escribió:
>>>
>>>> Thanks Alejandro.  My preference would be that you share whatever you
>>>> come up with the list so we can discuss it, before making a proposal that
>>>> would represent the committee.
>>>> -Iavor
>>>>
>>>> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
>>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>>
>>>>> OK by me.   Thank you
>>>>>
>>>>>
>>>>> Simon
>>>>>
>>>>>
>>>>>
>>>>> *From:* ghc-steering-committee <
>>>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>>>> Serrano Mena
>>>>> *Sent:* 29 September 2020 15:51
>>>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>>>> *Cc:* ghc-steering-committee at haskell.org
>>>>> *Subject:* Re: [ghc-steering-committee] GHC 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
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634558661&sdata=8ZlvyXrW6%2Bj2GdlPu6pIOOfbrV%2FdtLNdi8LyaTewKZA%3D&reserved=0>
>>>>>
>>>>>
>>>>>
>>>>> 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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634568657&sdata=GGl8%2FgEX%2FUMSS1IAp5x11aht%2F%2B6xQY8%2Fqa37aySDtPc%3D&reserved=0>
>>>>> %2F&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=yhLtqXE3QsviB6UGtcJmag7Hp1MMBc7YzV0NgOUL6io%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf
>>>>> |
>>>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>>>> |
>>>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
>>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>>> |  committee&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
>>>>> %7Cfa6e3a6bcdf04ed5
>>>>> |
>>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>>> |
>>>>> 199468575&amp;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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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
>>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634618629&sdata=VYF4w3uxxlh1%2Bxz%2B5zwXXRSjZpfh1ifAnxm0Qz1DLLc%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
>>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>>>>> <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%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634628621&sdata=vnuBB%2FuVonv5m0u%2FYYrHzoTmwNtQV4QLwTHMVD6YK9c%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/39979002/attachment-0001.html>

From trupill at gmail.com  Thu Oct  1 08:18:02 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 1 Oct 2020 10:18:02 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>

My idea is to make this a bit better before sending the PR to the
ghc-proposals repo (as Iavor suggested), but any preliminary feedback is
welcome.

Answering your questions (maybe Richard can also explain a bit, I'm giving
here my interpretation):
- By "complementing" we mean a (mostly subjective) idea that it goes with
the spirit of Haskell. For example, MultiParamTypeClasses extends what's
already there, and works well with the rest of features. If we suddenly
decided you can use Lisp-like syntax, that would not complement it's
current design.
- We want to keep all potentially unsafe features under flags.
IncoherentInstances should not be enabled by default because of its
behavior.
- I prefer to have a strict wording and then add exceptions. So I would say
conservativeness should be described as "no program ceases to be accepted".
- "Failure mode" is again not concrete, but the idea is that everything
which would make the developer experience worse by being enabled should not
be part of GHC2020.

El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<simonpj at microsoft.com>)
escribió:

> Thanks Alejandro. How do you want feedback?  The “discussed at this PR”
> link is broken.
>
>
>
> I think the criteria could be tightened up quite a bit.
>
>
>
>    - I don’t know what “The extensions *complement* the design of
>    standard Haskell” means.   What would be an example of something that
>    doesn’t complement it?
>
>
>
>    - I don’t know what “The extension is *not* to *gate-keep* an advanced
>    or potentially-unsafe feature” means.
>
>
>
>    - Item (1), conservative extension, is a bit ambiguous. Is says
>    “Mostly” but then “all programs”.  Which is your intent?
>
>
>
>    - What is a “new failure mode”?  Do you mean existing programs that
>    fail when the extension is on?  Or new programs that are trying to use the
>    new extension but get it wrong?   For the latter it’s hard to see how
>    they’d be rare.
>
>
>
> Simon
>
>
>
>
>
>
>
>
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 30 September 2020 21:06
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <
> rae at richarde.dev>; ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> Dear all,
>
> I've started working on a proposal for GHC2020. You can see the current
> status here:
> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042159563&sdata=YwM0vlfkVllsb4lwCRydeodKqs4mAbmBnYAss7jnrXA%3D&reserved=0>
>
>
>
> I noticed the list by Richard was not exhaustive. Those extensions are
> headed by "In discussion". Preferably we should make up our minds before
> presenting the proposal. I would say there are three big groups of
> proposals. Any feedback is welcome on that part.
>
>
>
> Regards,
>
> Alejandrp
>
>
>
> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
> iavor.diatchki at gmail.com>) escribió:
>
> Thanks Alejandro.  My preference would be that you share whatever you come
> up with the list so we can discuss it, before making a proposal that would
> represent the committee.
>
> -Iavor
>
>
>
> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> OK by me.   Thank you
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 29 September 2020 15:51
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042164548&sdata=wFIQt92hr82HcXuEwTXacMF%2BEuCqyr2tnokVzqVTEQQ%3D&reserved=0>
>
>
>
> 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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042169538&sdata=Ctr6M2HoRc2%2BbyWPFB4JNql2WIse14k4iWELijNVItQ%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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042174527&sdata=iiAtfwNwjAnv5k92F63GysP4XAvmFd9ibxIggJSisU4%3D&reserved=0>
> %2F&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042179516&sdata=3qCil%2FMoccFUJT5ewL2xNnAfltU6CrN4NG44tjlpv8E%3D&reserved=0>
> %7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042184514&sdata=fuk93MrXnqJKCb9DnER3g1PQH3CCqpxXb%2Bbd%2Fv87OjM%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042189496&sdata=FGlQfF33ahePm0M2O0zfQny8v7bAMczOIWqZyEZJyNc%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042194488&sdata=YqgMoMxpdRNYxxZN2PjexDFO%2B9Vbi8K1L%2BZ1cFhecII%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042199478&sdata=9nZFHqY8MyAbz3RWgDuYX%2B%2F2MUFkMMdFEwrFSUMmHtA%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042209458&sdata=l1fNq0SUpDnKgGJmKOea4OI69aFo7s61JUQzgU2RVSc%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042214451&sdata=JR7JtEo%2BF5akMRQtaqy4feJy%2FrtdHDoKAAOKh%2BNPmbc%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042219441&sdata=jK4hfemsYlEp5Y%2BGhWSXkte1gt9DMga8toTbWpD%2B7kc%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
> <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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042224430&sdata=jV83SWi62SM15AZgduDOULnRSb55grqKOI3RzX%2BlGPE%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
> <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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042229422&sdata=rOqBh76f6LeI%2F2Vz9yDjqIpu4w5dzkqOKfU7xg7REu0%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
> <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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042234412&sdata=A7yxkjePHouaA880w0Z2wISl7822I42gVHE1LRzBwZE%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
> <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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042239402&sdata=1HvIaICrDrNn%2Bje%2BqBDXkuNSqa9kqUZiUrtBNNoibNY%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
> <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%7C1fe9490f83c94088903e08d8657c590a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637370932042244393&sdata=QlkYJves2UnTUVlMabzOFybaXWJvZnxNA%2BnxcdMX1nU%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/02680c1c/attachment-0001.html>

From simonpj at microsoft.com  Thu Oct  1 08:32:15 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 1 Oct 2020 08:32:15 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
Message-ID: <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Thanks.  Rather than explaining to me, you could update the proposal?  (In due course.)

Simon

From: Alejandro Serrano Mena <trupill at gmail.com>
Sent: 01 October 2020 09:18
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Iavor Diatchki <iavor.diatchki at gmail.com>; Richard Eisenberg <rae at richarde.dev>; ghc-steering-committee at haskell.org
Subject: Re: [ghc-steering-committee] GHC 2020

My idea is to make this a bit better before sending the PR to the ghc-proposals repo (as Iavor suggested), but any preliminary feedback is welcome.

Answering your questions (maybe Richard can also explain a bit, I'm giving here my interpretation):
- By "complementing" we mean a (mostly subjective) idea that it goes with the spirit of Haskell. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement it's current design.
- We want to keep all potentially unsafe features under flags. IncoherentInstances should not be enabled by default because of its behavior.
- I prefer to have a strict wording and then add exceptions. So I would say conservativeness should be described as "no program ceases to be accepted".
- "Failure mode" is again not concrete, but the idea is that everything which would make the developer experience worse by being enabled should not be part of GHC2020.

El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<simonpj at microsoft.com<mailto:simonpj at microsoft.com>>) escribió:
Thanks Alejandro. How do you want feedback?  The “discussed at this PR” link is broken.

I think the criteria could be tightened up quite a bit.


  *   I don’t know what “The extensions complement the design of standard Haskell” means.   What would be an example of something that doesn’t complement it?


  *   I don’t know what “The extension is not to gate-keep an advanced or potentially-unsafe feature” means.


  *   Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”.  Which is your intent?



  *   What is a “new failure mode”?  Do you mean existing programs that fail when the extension is on?  Or new programs that are trying to use the new extension but get it wrong?   For the latter it’s hard to see how they’d be rare.

Simon





From: Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>>
Sent: 30 September 2020 21:06
To: Iavor Diatchki <iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>
Cc: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>; Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>; ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] GHC 2020

Dear all,
I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0>

I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.

Regards,
Alejandrp

El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>) escribió:
Thanks Alejandro.  My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee.
-Iavor

On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:
OK by me.   Thank you

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
Sent: 29 September 2020 15:51
To: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] GHC 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<mailto: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<mailto: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<mailto: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<mailto: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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0>

On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com<mailto: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<mailto: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<mailto: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<mailto:trupill at gmail.com>>
Sent: 08 September 2020 09:13
To: Simon Peyton Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>>
Cc: Richard Eisenberg <rae at richarde.dev<mailto:rae at richarde.dev>>; Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org<mailto: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<mailto: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<mailto:bounces at haskell.org>> On Behalf Of Richard Eisenberg
|  Sent: 02 September 2020 14:57
|  To: Eric Seidel <eric at seidel.io<mailto:eric at seidel.io>>
|  Cc: ghc-steering-committee at haskell.org<mailto: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<mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%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<mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0>%2F&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0>%7Cfa6e3a6bcdf
|  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
|  &amp;reserved=0
|  >>
|  >>
|  >> _______________________________________________
|  >> ghc-steering-committee mailing list
|  >> ghc-steering-committee at haskell.org<mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
|  >
|  > _______________________________________________
|  > ghc-steering-committee mailing list
|  > ghc-steering-committee at haskell.org<mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
|  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
|  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
|  amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0>

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/07a1254e/attachment-0001.html>

From mail at joachim-breitner.de  Thu Oct  1 08:58:48 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 01 Oct 2020 10:58:48 +0200
Subject: [ghc-steering-committee]  Please review #283: Local modules,
 Shepherd: Arnaud
Message-ID: <e4e79a3dd4f558b5c3e29b38be9b8309620f8321.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Local Modules
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/283
https://github.com/goldfirere/ghc-proposals/blob/local-modules/proposals/0000-local-modules.rst

I’ll propose Arnaud as the shepherd. Please note that Richard writes

>
The main alternative to this proposal is #295. It is probably worth
> it
for at least the committee shepherd to read #295 in concert with 
> this
current proposal, to see which approach they like more.

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

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



From trupill at gmail.com  Thu Oct  1 10:02:15 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 1 Oct 2020 12:02:15 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
	recommendation: accept
In-Reply-To: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
Message-ID: <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>

Dear all,
I recommend that we accept this proposal. The only problematic (read, not
backwards-compatible) bit is the case of a type class having instances for
both `Nat` and `Natural`, but that seems very unlikely.

Something which I thought about was whether any of `Nat` or `Natural` were
implementing something akin to Peano naturals (so we could have inductive
instances working on Zero and (Succ n)), both none of both do, so the
alignment seems correct to me.

Regards,
Alejandro

El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<
mail at joachim-breitner.de>) escribió:

> Dear Committee,
>
> this is your secretary speaking:
>
> Unify Nat and Natural
> has been proposed by Richard
> https://github.com/ghc-proposals/ghc-proposals/pull/364
>
> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
>
> I’ll propose Alejandro as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/7361f362/attachment.html>

From mail at joachim-breitner.de  Thu Oct  1 10:06:03 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 01 Oct 2020 12:06:03 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
Message-ID: <f812a32251b970ebc465f9de5c46c80d52981f03.camel@joachim-breitner.de>

Hi

in a recent project of mine, the difference between Nat and Natural was
a serious hurdle in using dependentish types, so I am in favor. (Text
and Symbol was the other, so this would not have unblocked me, but
still).

Cheers,
Joachim

Am Donnerstag, den 01.10.2020, 12:02 +0200 schrieb Alejandro Serrano
Mena:
> Dear all,
> I recommend that we accept this proposal. The only problematic (read, not backwards-compatible) bit is the case of a type class having instances for both `Nat` and `Natural`, but that seems very unlikely.
> 
> Something which I thought about was whether any of `Nat` or `Natural` were implementing something akin to Peano naturals (so we could have inductive instances working on Zero and (Succ n)), both none of both do, so the alignment seems correct to me.
> 
> Regards,
> Alejandro
> 
> El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<mail at joachim-breitner.de>) escribió:
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > Unify Nat and Natural
> > has been proposed by Richard
> > https://github.com/ghc-proposals/ghc-proposals/pull/364
> > https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
> > 
> > I’ll propose Alejandro as the shepherd.
> > 
> > Please guide us to a conclusion as outlined in 
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > 
> > Thanks,
> > Joachim
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Thu Oct  1 10:11:14 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Thu, 1 Oct 2020 10:11:14 +0000
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
	recommendation: accept
In-Reply-To: <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
Message-ID: <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>

Aye.   Tidies this up, and I see no downside.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 01 October 2020 11:02
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] #364: Unify Nat and Natural, recommendation: accept

Dear all,
I recommend that we accept this proposal. The only problematic (read, not backwards-compatible) bit is the case of a type class having instances for both `Nat` and `Natural`, but that seems very unlikely.

Something which I thought about was whether any of `Nat` or `Natural` were implementing something akin to Peano naturals (so we could have inductive instances working on Zero and (Succ n)), both none of both do, so the alignment seems correct to me.

Regards,
Alejandro

El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>) escribió:
Dear Committee,

this is your secretary speaking:

Unify Nat and Natural
has been proposed by Richard
https://github.com/ghc-proposals/ghc-proposals/pull/364<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F364&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=JSTuh5g4KrmxgwJRsQ9m8QXa0TnGxGVr%2FZUrbK7a%2FLA%3D&reserved=0>
https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fnatural%2Fproposals%2F0000-unify-natural.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=KYno%2B%2FA4WGYaDt5oV5VxCH7vWDn2QAU%2FSUjyR%2FZ6Yao%3D&reserved=0>

I’ll propose Alejandro as the shepherd.

Please guide us to a conclusion as outlined in
https://github.com/ghc-proposals/ghc-proposals#committee-process<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=%2F%2BKk8v8%2Fe6W15doiLm0Z2FM0BaL0KVtUlwZZlzws9sM%3D&reserved=0>

Thanks,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
  http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=JejYCscHAtZenQNNO0vru0WP%2BCPIPEo3%2Bj%2Fq76wJKMI%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=KMmToVSXLW9cGxucsfLoELO8Eda6YakAKtZDk%2BAnSzU%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/5f3b6562/attachment-0001.html>

From arnaud.spiwack at tweag.io  Thu Oct  1 11:21:53 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 1 Oct 2020 13:21:53 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
 <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>

I fail to find a downside as well. I would still like to insist on the
motivation section to feature an illustrative example before we merge the
proposal, though. But the rest is good with me.

On Thu, Oct 1, 2020 at 12:11 PM Simon Peyton Jones via
ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:

> Aye.   Tidies this up, and I see no downside.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 01 October 2020 11:02
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* [ghc-steering-committee] #364: Unify Nat and Natural,
> recommendation: accept
>
>
>
> Dear all,
>
> I recommend that we accept this proposal. The only problematic (read, not
> backwards-compatible) bit is the case of a type class having instances for
> both `Nat` and `Natural`, but that seems very unlikely.
>
>
>
> Something which I thought about was whether any of `Nat` or `Natural` were
> implementing something akin to Peano naturals (so we could have inductive
> instances working on Zero and (Succ n)), both none of both do, so the
> alignment seems correct to me.
>
>
>
> Regards,
>
> Alejandro
>
>
>
> El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<
> mail at joachim-breitner.de>) escribió:
>
> Dear Committee,
>
> this is your secretary speaking:
>
> Unify Nat and Natural
> has been proposed by Richard
> https://github.com/ghc-proposals/ghc-proposals/pull/364
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F364&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=JSTuh5g4KrmxgwJRsQ9m8QXa0TnGxGVr%2FZUrbK7a%2FLA%3D&reserved=0>
>
> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fnatural%2Fproposals%2F0000-unify-natural.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=KYno%2B%2FA4WGYaDt5oV5VxCH7vWDn2QAU%2FSUjyR%2FZ6Yao%3D&reserved=0>
>
> I’ll propose Alejandro as the shepherd.
>
> Please guide us to a conclusion as outlined in
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=%2F%2BKk8v8%2Fe6W15doiLm0Z2FM0BaL0KVtUlwZZlzws9sM%3D&reserved=0>
>
> Thanks,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=JejYCscHAtZenQNNO0vru0WP%2BCPIPEo3%2Bj%2Fq76wJKMI%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
> <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%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=KMmToVSXLW9cGxucsfLoELO8Eda6YakAKtZDk%2BAnSzU%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/6ffb6735/attachment.html>

From rae at richarde.dev  Thu Oct  1 15:16:36 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 1 Oct 2020 15:16:36 +0000
Subject: [ghc-steering-committee] Please review #283: Local modules,
 Shepherd: Arnaud
In-Reply-To: <e4e79a3dd4f558b5c3e29b38be9b8309620f8321.camel@joachim-breitner.de>
References: <e4e79a3dd4f558b5c3e29b38be9b8309620f8321.camel@joachim-breitner.de>
Message-ID: <010f0174e4bc8d18-c14c241c-a734-4455-a5a9-59653491f8b7-000000@us-east-2.amazonses.com>



> On Oct 1, 2020, at 4:58 AM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
>> 
> The main alternative to this proposal is #295. It is probably worth
>> it
> for at least the committee shepherd to read #295 in concert with 
>> this
> current proposal, to see which approach they like more.

Since I wrote that on #283, Michael (the author of #295) effectively retracted that proposal, so it needn't be considered in tandem. For the sake of completeness: a comment (https://github.com/ghc-proposals/ghc-proposals/pull/295#issuecomment-702044502 <https://github.com/ghc-proposals/ghc-proposals/pull/295#issuecomment-702044502>) on #295 suggests a (in my opinion) very vague alternative approach building from #295 that could be considered an alternative to #283.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/5ef46074/attachment.html>

From iavor.diatchki at gmail.com  Thu Oct  1 16:10:05 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 1 Oct 2020 09:10:05 -0700
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>

I quite strongly disagree with a bunch of the classifications on
Alejandro's link but I have no idea *why* he thinks they match the
criteria, or what that even means.   Rather than having an unstructured
discussion about "I don't agree with this or that", I'd encourage us to
avoid the "big bang" approach, of having a page with all extensions, and do
something more focused.    For example, in the extensions I sent in the
original e-mail of this thread are grouped more or less "by topic", and I
think we should do something similar in the discussion.

For the sake of concreteness, why don't we start by discussing extensions
related to Haskell's deriving mechanism? In Alejandro's current link there
are a whole lot of these listed as "matching all criteria", but not all of
them are compatible with each other, so they should not be all part of GHC
2020. On this topic, the extensions I think should be part of GHC2020 would
be:
   1. EmptyDataDeriving
   2. StandaloneDeriving
   3. DeriveGeneric
   4. DeriveLift

I don't think any of these are likely to affect existing code bases, and I
don't think listing them as an explicit extension gives you any information
that you couldn't easily obtain by just looking at the code.
I don't use (1) a lot but I think it makes the language more consistent.
(2) I use this sometimes, and having an extension to enable it doesn't
really add any extra information, and (3) and (4) are for Generics and
Template Haskell, both of which are fairly common and not likely to go away.

Other extensions that I use quite often are `GeneralizedNewtypeDeriving`,
`DeriveTraversible`.  I don't think we should add
`GenerelizedNewtypeDeriving` because it brings in the whole "role"
annotation machinery.  I know why we need it at the moment, but it doesn't
seem particularly elegant.  I also tend to use it in extremely restricted
ways, mostly to derive `Monad` instances.   `DeriveTraversible` seems nice
and I do use it, but I think it potentially interferes with the other
deriving techniques (e.g. GND).

-Iavor
PS: I'd be up for trying out something like Kialo if we'd prefer to use a
tool rather than having the discussion over e-mail

On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> Thanks.  Rather than explaining to me, you could update the proposal?  (In
> due course.)
>
>
>
> Simon
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 01 October 2020 09:18
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Iavor Diatchki <iavor.diatchki at gmail.com>; Richard Eisenberg <
> rae at richarde.dev>; ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> My idea is to make this a bit better before sending the PR to the
> ghc-proposals repo (as Iavor suggested), but any preliminary feedback is
> welcome.
>
>
>
> Answering your questions (maybe Richard can also explain a bit, I'm giving
> here my interpretation):
>
> - By "complementing" we mean a (mostly subjective) idea that it goes with
> the spirit of Haskell. For example, MultiParamTypeClasses extends what's
> already there, and works well with the rest of features. If we suddenly
> decided you can use Lisp-like syntax, that would not complement it's
> current design.
>
> - We want to keep all potentially unsafe features under flags.
> IncoherentInstances should not be enabled by default because of its
> behavior.
>
> - I prefer to have a strict wording and then add exceptions. So I would
> say conservativeness should be described as "no program ceases to be
> accepted".
>
> - "Failure mode" is again not concrete, but the idea is that everything
> which would make the developer experience worse by being enabled should not
> be part of GHC2020.
>
>
>
> El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<
> simonpj at microsoft.com>) escribió:
>
> Thanks Alejandro. How do you want feedback?  The “discussed at this PR”
> link is broken.
>
>
>
> I think the criteria could be tightened up quite a bit.
>
>
>
>    - I don’t know what “The extensions *complement* the design of
>    standard Haskell” means.   What would be an example of something that
>    doesn’t complement it?
>
>
>
>    - I don’t know what “The extension is *not* to *gate-keep* an advanced
>    or potentially-unsafe feature” means.
>
>
>
>    - Item (1), conservative extension, is a bit ambiguous. Is says
>    “Mostly” but then “all programs”.  Which is your intent?
>
>
>
>    - What is a “new failure mode”?  Do you mean existing programs that
>    fail when the extension is on?  Or new programs that are trying to use the
>    new extension but get it wrong?   For the latter it’s hard to see how
>    they’d be rare.
>
>
>
> Simon
>
>
>
>
>
>
>
>
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 30 September 2020 21:06
> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <
> rae at richarde.dev>; ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 2020
>
>
>
> Dear all,
>
> I've started working on a proposal for GHC2020. You can see the current
> status here:
> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0>
>
>
>
> I noticed the list by Richard was not exhaustive. Those extensions are
> headed by "In discussion". Preferably we should make up our minds before
> presenting the proposal. I would say there are three big groups of
> proposals. Any feedback is welcome on that part.
>
>
>
> Regards,
>
> Alejandrp
>
>
>
> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
> iavor.diatchki at gmail.com>) escribió:
>
> Thanks Alejandro.  My preference would be that you share whatever you come
> up with the list so we can discuss it, before making a proposal that would
> represent the committee.
>
> -Iavor
>
>
>
> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
> OK by me.   Thank you
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Alejandro Serrano Mena
> *Sent:* 29 September 2020 15:51
> *To:* Richard Eisenberg <rae at richarde.dev>
> *Cc:* ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] GHC 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
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0>
>
>
>
> 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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0>
> %2F&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0>
> %7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0>
> %7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%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
> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/df8408dc/attachment-0001.html>

From iavor.diatchki at gmail.com  Thu Oct  1 16:14:13 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 1 Oct 2020 09:14:13 -0700
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
 <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>
Message-ID: <CAGK9nuqLen3BPsMQcdCRc4NSF4DXik3UW+S29V06+CuxBXKZ4Q@mail.gmail.com>

I am fine with this change too.

Joachim, I'd be curious to see an example of the hurdle you run into, if
there is a simple example illustrating it.

On Thu, Oct 1, 2020 at 4:22 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> I fail to find a downside as well. I would still like to insist on the
> motivation section to feature an illustrative example before we merge the
> proposal, though. But the rest is good with me.
>
> On Thu, Oct 1, 2020 at 12:11 PM Simon Peyton Jones via
> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>
>> Aye.   Tidies this up, and I see no downside.
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>> Serrano Mena
>> *Sent:* 01 October 2020 11:02
>> *To:* Joachim Breitner <mail at joachim-breitner.de>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* [ghc-steering-committee] #364: Unify Nat and Natural,
>> recommendation: accept
>>
>>
>>
>> Dear all,
>>
>> I recommend that we accept this proposal. The only problematic (read, not
>> backwards-compatible) bit is the case of a type class having instances for
>> both `Nat` and `Natural`, but that seems very unlikely.
>>
>>
>>
>> Something which I thought about was whether any of `Nat` or `Natural`
>> were implementing something akin to Peano naturals (so we could have
>> inductive instances working on Zero and (Succ n)), both none of both do, so
>> the alignment seems correct to me.
>>
>>
>>
>> Regards,
>>
>> Alejandro
>>
>>
>>
>> El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<
>> mail at joachim-breitner.de>) escribió:
>>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Unify Nat and Natural
>> has been proposed by Richard
>> https://github.com/ghc-proposals/ghc-proposals/pull/364
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F364&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=JSTuh5g4KrmxgwJRsQ9m8QXa0TnGxGVr%2FZUrbK7a%2FLA%3D&reserved=0>
>>
>> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fnatural%2Fproposals%2F0000-unify-natural.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=KYno%2B%2FA4WGYaDt5oV5VxCH7vWDn2QAU%2FSUjyR%2FZ6Yao%3D&reserved=0>
>>
>> I’ll propose Alejandro as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494036876&sdata=%2F%2BKk8v8%2Fe6W15doiLm0Z2FM0BaL0KVtUlwZZlzws9sM%3D&reserved=0>
>>
>> Thanks,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=JejYCscHAtZenQNNO0vru0WP%2BCPIPEo3%2Bj%2Fq76wJKMI%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
>> <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%7Ccf838f8219a74bf4c26608d865f11f20%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371434494046841&sdata=KMmToVSXLW9cGxucsfLoELO8Eda6YakAKtZDk%2BAnSzU%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/c2e9f470/attachment.html>

From mail at joachim-breitner.de  Thu Oct  1 16:44:57 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 01 Oct 2020 18:44:57 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CAGK9nuqLen3BPsMQcdCRc4NSF4DXik3UW+S29V06+CuxBXKZ4Q@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
 <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>
 <CAGK9nuqLen3BPsMQcdCRc4NSF4DXik3UW+S29V06+CuxBXKZ4Q@mail.gmail.com>
Message-ID: <919ab229a9ee509ce48a2da8a10da767c89bbd07.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 01.10.2020, 09:14 -0700 schrieb Iavor Diatchki:
> Joachim, I'd be curious to see an example of the hurdle you run into, if there is a simple example illustrating it.

I wanted to use a datatype (that describes an typed AST) both as values
(where I needed Text or String) and as types (where needed Symbol). I
resorted to a hack like

data FieldName
   = N Symbol -- ^ a properly named field
   | N' T.Text -- ^ Use this in terms (usually not needed)
   | H Nat -- ^ a field hash. Should fit in 32 bit. Also used for tuples 
   | H' Word32 -- ^ Use this in terms (mostly internal)


data SFieldName (n :: FieldName) where
    SN :: KnownSymbol s => Proxy s -> SFieldName ('N s)
    SH :: KnownNat n => Proxy n -> SFieldName ('H n)

fromSFieldName :: SFieldName n -> FieldName
fromSFieldName (SN p) = N' (T.pack (symbolVal p))
fromSFieldName (SH p) = H' (fromIntegral (natVal p))

class Typeable fn => KnownFieldName (fn :: FieldName) where fieldName :: SFieldName fn
instance KnownSymbol s => KnownFieldName ('N s) where
    fieldName = SN (Proxy @s)
instance KnownNat s => KnownFieldName ('H s) where
    fieldName = SH (Proxy @s)

Fullcode at 
https://github.com/nomeata/haskell-candid/blob/2feb0cdbdbfa74f3e4373066b1d5827e5038df9d/src/Codec/Candid/Core.hs#L163-L167

Eventually I just used less type-level computation (and otherwise
greatly restructued that code, so don’t worry too much about helping
here). Maybe using a library like singleton might have made that
easier, or maybe there are tricks that I missed, and I did it all
wrong.


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



From iavor.diatchki at gmail.com  Thu Oct  1 17:07:18 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 1 Oct 2020 10:07:18 -0700
Subject: [ghc-steering-committee] Please review #281: Visible 'forall' in
	types of terms
Message-ID: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>

Hello,

Proposal #281 is ready for review by the committee.   My recommendation is
to accept it,  I've
written a summary of my understanding to the proposal and my recommendation
on the GitHub
thread, accessible through these links:

https://github.com/ghc-proposals/ghc-proposals/pull/281
https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst

Let the discussion begin!

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

From trupill at gmail.com  Thu Oct  1 19:34:45 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Thu, 1 Oct 2020 21:34:45 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
Message-ID: <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>

My idea was to turn the original wiki page
https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 into an actual
proposal, so we can open it to discussion. Except for a few extensions, I
copied the original acceptance list, since people seemed to mostly agree
with them.

In any case, the aim was to agree on some set of extensions that we could
propose as a Committee, before opening to further consultation, especially
in order to agree on a set of criteria. It could well be that we should
refrain from adding some of them; it seems that you think that roles for
example are not there yet, so we should remove any extension which uses
them implicitly.

I am happy to go back to the original thread you sent, and tell which are
those extensions which I consider fine. But as you said, that would make
the discussion terribly inefficient. Any thoughts on the approach to
follow? Otherwise I feel we'll be forever in a sort of deadlock. I am also
happy with taking Iavor's original list, turning it into a proposal, and
let the community speak. But then we need a good story about why some
common extensions, like MultiParamTypeClasses, are not included.

Regards,
Alejandro

El jue., 1 oct. 2020 a las 18:10, Iavor Diatchki (<iavor.diatchki at gmail.com>)
escribió:

> I quite strongly disagree with a bunch of the classifications on
> Alejandro's link but I have no idea *why* he thinks they match the
> criteria, or what that even means.   Rather than having an unstructured
> discussion about "I don't agree with this or that", I'd encourage us to
> avoid the "big bang" approach, of having a page with all extensions, and do
> something more focused.    For example, in the extensions I sent in the
> original e-mail of this thread are grouped more or less "by topic", and I
> think we should do something similar in the discussion.
>
> For the sake of concreteness, why don't we start by discussing extensions
> related to Haskell's deriving mechanism? In Alejandro's current link there
> are a whole lot of these listed as "matching all criteria", but not all of
> them are compatible with each other, so they should not be all part of GHC
> 2020. On this topic, the extensions I think should be part of GHC2020 would
> be:
>    1. EmptyDataDeriving
>    2. StandaloneDeriving
>    3. DeriveGeneric
>    4. DeriveLift
>
> I don't think any of these are likely to affect existing code bases, and I
> don't think listing them as an explicit extension gives you any information
> that you couldn't easily obtain by just looking at the code.
> I don't use (1) a lot but I think it makes the language more consistent.
> (2) I use this sometimes, and having an extension to enable it doesn't
> really add any extra information, and (3) and (4) are for Generics and
> Template Haskell, both of which are fairly common and not likely to go away.
>
> Other extensions that I use quite often are `GeneralizedNewtypeDeriving`,
> `DeriveTraversible`.  I don't think we should add
> `GenerelizedNewtypeDeriving` because it brings in the whole "role"
> annotation machinery.  I know why we need it at the moment, but it doesn't
> seem particularly elegant.  I also tend to use it in extremely restricted
> ways, mostly to derive `Monad` instances.   `DeriveTraversible` seems nice
> and I do use it, but I think it potentially interferes with the other
> deriving techniques (e.g. GND).
>
> -Iavor
> PS: I'd be up for trying out something like Kialo if we'd prefer to use a
> tool rather than having the discussion over e-mail
>
> On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones <simonpj at microsoft.com>
> wrote:
>
>> Thanks.  Rather than explaining to me, you could update the proposal?
>> (In due course.)
>>
>>
>>
>> Simon
>>
>>
>>
>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>> *Sent:* 01 October 2020 09:18
>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>> *Cc:* Iavor Diatchki <iavor.diatchki at gmail.com>; Richard Eisenberg <
>> rae at richarde.dev>; ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>
>>
>>
>> My idea is to make this a bit better before sending the PR to the
>> ghc-proposals repo (as Iavor suggested), but any preliminary feedback is
>> welcome.
>>
>>
>>
>> Answering your questions (maybe Richard can also explain a bit, I'm
>> giving here my interpretation):
>>
>> - By "complementing" we mean a (mostly subjective) idea that it goes with
>> the spirit of Haskell. For example, MultiParamTypeClasses extends what's
>> already there, and works well with the rest of features. If we suddenly
>> decided you can use Lisp-like syntax, that would not complement it's
>> current design.
>>
>> - We want to keep all potentially unsafe features under flags.
>> IncoherentInstances should not be enabled by default because of its
>> behavior.
>>
>> - I prefer to have a strict wording and then add exceptions. So I would
>> say conservativeness should be described as "no program ceases to be
>> accepted".
>>
>> - "Failure mode" is again not concrete, but the idea is that everything
>> which would make the developer experience worse by being enabled should not
>> be part of GHC2020.
>>
>>
>>
>> El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<
>> simonpj at microsoft.com>) escribió:
>>
>> Thanks Alejandro. How do you want feedback?  The “discussed at this PR”
>> link is broken.
>>
>>
>>
>> I think the criteria could be tightened up quite a bit.
>>
>>
>>
>>    - I don’t know what “The extensions *complement* the design of
>>    standard Haskell” means.   What would be an example of something that
>>    doesn’t complement it?
>>
>>
>>
>>    - I don’t know what “The extension is *not* to *gate-keep* an
>>    advanced or potentially-unsafe feature” means.
>>
>>
>>
>>    - Item (1), conservative extension, is a bit ambiguous. Is says
>>    “Mostly” but then “all programs”.  Which is your intent?
>>
>>
>>
>>    - What is a “new failure mode”?  Do you mean existing programs that
>>    fail when the extension is on?  Or new programs that are trying to use the
>>    new extension but get it wrong?   For the latter it’s hard to see how
>>    they’d be rare.
>>
>>
>>
>> Simon
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>> *Sent:* 30 September 2020 21:06
>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <
>> rae at richarde.dev>; ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>
>>
>>
>> Dear all,
>>
>> I've started working on a proposal for GHC2020. You can see the current
>> status here:
>> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0>
>>
>>
>>
>> I noticed the list by Richard was not exhaustive. Those extensions are
>> headed by "In discussion". Preferably we should make up our minds before
>> presenting the proposal. I would say there are three big groups of
>> proposals. Any feedback is welcome on that part.
>>
>>
>>
>> Regards,
>>
>> Alejandrp
>>
>>
>>
>> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
>> iavor.diatchki at gmail.com>) escribió:
>>
>> Thanks Alejandro.  My preference would be that you share whatever you
>> come up with the list so we can discuss it, before making a proposal that
>> would represent the committee.
>>
>> -Iavor
>>
>>
>>
>> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>
>> OK by me.   Thank you
>>
>>
>> Simon
>>
>>
>>
>> *From:* ghc-steering-committee <
>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>> Serrano Mena
>> *Sent:* 29 September 2020 15:51
>> *To:* Richard Eisenberg <rae at richarde.dev>
>> *Cc:* ghc-steering-committee at haskell.org
>> *Subject:* Re: [ghc-steering-committee] GHC 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
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0>
>>
>>
>>
>> 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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0>
>> %2F&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0>
>> %7Cfa6e3a6bcdf
>> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0>
>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0>
>> %7Cfa6e3a6bcdf04ed5
>> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>> |  199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%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
>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201001/9e7e6f3e/attachment-0001.html>

From arnaud.spiwack at tweag.io  Fri Oct  2 06:18:49 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Fri, 2 Oct 2020 08:18:49 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
 <VI1PR83MB04291464E868C13A06DF7CBAAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAH6fHQ=+0V1HPi_dPaMDbBCOseyHRTNA0Jk8X06=QcrbGRqMCw@mail.gmail.com>
Message-ID: <CAH6fHQkH3Ebrux6n5tm8prptBXR5=7OkqceGOb1WFG_dNZ4NFg@mail.gmail.com>

On Thu, Oct 1, 2020 at 1:21 PM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> I fail to find a downside as well. I would still like to insist on the
> motivation section to feature an illustrative example before we merge the
> proposal, though. But the rest is good with me.
>

Which has now been addressed. So I'm all good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201002/f1b3ef09/attachment.html>

From bravit111 at gmail.com  Fri Oct  2 11:47:33 2020
From: bravit111 at gmail.com (Vitaly Bragilevsky)
Date: Fri, 2 Oct 2020 14:47:33 +0300
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
Message-ID: <CALpVSmN9h4-H8Xw8ic4gmO2MNZJaQOSK7OAzMY82Qo5HfHaD4g@mail.gmail.com>

Hi,

I support the recommendation to accept this proposal.

Vitaly

чт, 1 окт. 2020 г. в 13:02, Alejandro Serrano Mena <trupill at gmail.com>:

> Dear all,
> I recommend that we accept this proposal. The only problematic (read, not
> backwards-compatible) bit is the case of a type class having instances for
> both `Nat` and `Natural`, but that seems very unlikely.
>
> Something which I thought about was whether any of `Nat` or `Natural` were
> implementing something akin to Peano naturals (so we could have inductive
> instances working on Zero and (Succ n)), both none of both do, so the
> alignment seems correct to me.
>
> Regards,
> Alejandro
>
> El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<
> mail at joachim-breitner.de>) escribió:
>
>> Dear Committee,
>>
>> this is your secretary speaking:
>>
>> Unify Nat and Natural
>> has been proposed by Richard
>> https://github.com/ghc-proposals/ghc-proposals/pull/364
>>
>> https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
>>
>> I’ll propose Alejandro as the shepherd.
>>
>> Please guide us to a conclusion as outlined in
>> https://github.com/ghc-proposals/ghc-proposals#committee-process
>>
>> Thanks,
>> Joachim
>> --
>> Joachim Breitner
>>   mail at joachim-breitner.de
>>   http://www.joachim-breitner.de/
>>
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201002/247b19e3/attachment.html>

From rae at richarde.dev  Fri Oct  2 15:33:49 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 2 Oct 2020 15:33:49 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
Message-ID: <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>

A few scattered thoughts:

* I don't see a particular need to debate on this list separately from a debate more in public. This list is public, anyway! And having the debate organized from as early as possible seems better.

* I feel strongly that we should find a venue where we can discuss individual extensions on separately-marshalled threads, not in one monolithic clump. One idea (I think?) that was floated was to start a new repo (in the ghc-proposals org), where we can make a ticket for any contested extension. Kialo is another idea (assuming it supports separate threads for separate ideas); I have no experience. In the end, I don't care much about where this happens, as long as separate threads are indeed separable.

* Debating the criteria seems like a worthy place to start. That *could* be done over email, but I think a proposal is better.

Maybe this suggests the following structure:

* A ghc-proposal that sets out the criteria for inclusion -- but does not opine on any extensions (except perhaps as illustrations of a criterion). This can get debated and accepted in the usual fashion, except that it might form a new document in the top level of our repo, not just another proposal. This initial proposal can also set out the way to stage the rest of the debate.

* Upon acceptance, we proceed with the approach outlined in the first step, such as the extra repo or the Kialo space.

* Profit.

Richard

> On Oct 1, 2020, at 3:34 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> My idea was to turn the original wiki page https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 <https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020> into an actual proposal, so we can open it to discussion. Except for a few extensions, I copied the original acceptance list, since people seemed to mostly agree with them.
> 
> In any case, the aim was to agree on some set of extensions that we could propose as a Committee, before opening to further consultation, especially in order to agree on a set of criteria. It could well be that we should refrain from adding some of them; it seems that you think that roles for example are not there yet, so we should remove any extension which uses them implicitly.
> 
> I am happy to go back to the original thread you sent, and tell which are those extensions which I consider fine. But as you said, that would make the discussion terribly inefficient. Any thoughts on the approach to follow? Otherwise I feel we'll be forever in a sort of deadlock. I am also happy with taking Iavor's original list, turning it into a proposal, and let the community speak. But then we need a good story about why some common extensions, like MultiParamTypeClasses, are not included.
> 
> Regards,
> Alejandro
> 
> El jue., 1 oct. 2020 a las 18:10, Iavor Diatchki (<iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>) escribió:
> I quite strongly disagree with a bunch of the classifications on Alejandro's link but I have no idea *why* he thinks they match the criteria, or what that even means.   Rather than having an unstructured discussion about "I don't agree with this or that", I'd encourage us to avoid the "big bang" approach, of having a page with all extensions, and do something more focused.    For example, in the extensions I sent in the original e-mail of this thread are grouped more or less "by topic", and I think we should do something similar in the discussion.
> 
> For the sake of concreteness, why don't we start by discussing extensions related to Haskell's deriving mechanism? In Alejandro's current link there are a whole lot of these listed as "matching all criteria", but not all of them are compatible with each other, so they should not be all part of GHC 2020. On this topic, the extensions I think should be part of GHC2020 would be:
>    1. EmptyDataDeriving
>    2. StandaloneDeriving 
>    3. DeriveGeneric
>    4. DeriveLift
> 
> I don't think any of these are likely to affect existing code bases, and I don't think listing them as an explicit extension gives you any information that you couldn't easily obtain by just looking at the code.
> I don't use (1) a lot but I think it makes the language more consistent.  (2) I use this sometimes, and having an extension to enable it doesn't really add any extra information, and (3) and (4) are for Generics and Template Haskell, both of which are fairly common and not likely to go away.
> 
> Other extensions that I use quite often are `GeneralizedNewtypeDeriving`, `DeriveTraversible`.  I don't think we should add `GenerelizedNewtypeDeriving` because it brings in the whole "role" annotation machinery.  I know why we need it at the moment, but it doesn't seem particularly elegant.  I also tend to use it in extremely restricted ways, mostly to derive `Monad` instances.   `DeriveTraversible` seems nice and I do use it, but I think it potentially interferes with the other deriving techniques (e.g. GND).
> 
> -Iavor
> PS: I'd be up for trying out something like Kialo if we'd prefer to use a tool rather than having the discussion over e-mail
> 
> On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>> wrote:
> Thanks.  Rather than explaining to me, you could update the proposal?  (In due course.)
> 
>  
> 
> Simon
> 
>  
> 
> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> 
> Sent: 01 October 2020 09:18
> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Cc: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>; Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] GHC 2020
> 
>  
> 
> My idea is to make this a bit better before sending the PR to the ghc-proposals repo (as Iavor suggested), but any preliminary feedback is welcome.
> 
>  
> 
> Answering your questions (maybe Richard can also explain a bit, I'm giving here my interpretation):
> 
> - By "complementing" we mean a (mostly subjective) idea that it goes with the spirit of Haskell. For example, MultiParamTypeClasses extends what's already there, and works well with the rest of features. If we suddenly decided you can use Lisp-like syntax, that would not complement it's current design.
> 
> - We want to keep all potentially unsafe features under flags. IncoherentInstances should not be enabled by default because of its behavior.
> 
> - I prefer to have a strict wording and then add exceptions. So I would say conservativeness should be described as "no program ceases to be accepted".
> 
> - "Failure mode" is again not concrete, but the idea is that everything which would make the developer experience worse by being enabled should not be part of GHC2020.
> 
>  
> 
> El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<simonpj at microsoft.com <mailto:simonpj at microsoft.com>>) escribió:
> 
> Thanks Alejandro. How do you want feedback?  The “discussed at this PR” link is broken.
> 
>  
> 
> I think the criteria could be tightened up quite a bit.
> 
>  
> 
> I don’t know what “The extensions complement the design of standard Haskell” means.   What would be an example of something that doesn’t complement it?
>  
> 
> I don’t know what “The extension is not to gate-keep an advanced or potentially-unsafe feature” means.
>  
> 
> Item (1), conservative extension, is a bit ambiguous. Is says “Mostly” but then “all programs”.  Which is your intent?
>  
> 
> What is a “new failure mode”?  Do you mean existing programs that fail when the extension is on?  Or new programs that are trying to use the new extension but get it wrong?   For the latter it’s hard to see how they’d be rare.
>  
> 
> Simon
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> From: Alejandro Serrano Mena <trupill at gmail.com <mailto:trupill at gmail.com>> 
> Sent: 30 September 2020 21:06
> To: Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>
> Cc: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>; Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>; ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] GHC 2020
> 
>  
> 
> Dear all,
> 
> I've started working on a proposal for GHC2020. You can see the current status here: https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0>
>  
> 
> I noticed the list by Richard was not exhaustive. Those extensions are headed by "In discussion". Preferably we should make up our minds before presenting the proposal. I would say there are three big groups of proposals. Any feedback is welcome on that part.
> 
>  
> 
> Regards,
> 
> Alejandrp
> 
>  
> 
> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>>) escribió:
> 
> Thanks Alejandro.  My preference would be that you share whatever you come up with the list so we can discuss it, before making a proposal that would represent the committee. 
> 
> -Iavor
> 
>  
> 
> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>> wrote:
> 
> OK by me.   Thank you
> 
> 
> Simon
> 
>  
> 
> From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org <mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
> Sent: 29 September 2020 15:51
> To: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>
> Cc: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> Subject: Re: [ghc-steering-committee] GHC 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 <mailto: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 <mailto: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:
> 
> The extension is (mostly) conservative: All programs that were accepted without the extension remain accepted, and with the same meaning.
> 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.)
> The extensions complement the design of standard Haskell. (This one seems the most subjective.)
> The extension has been -- and can reasonably be predicted to remain -- stable.
> The extension is not to gate-keep an advanced or potentially-unsafe feature.
> 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 <mailto: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 <mailto: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 <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0>
>  
> 
> On Wed, Sep 9, 2020 at 12:17 PM Alejandro Serrano Mena <trupill at gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto:trupill at gmail.com>> 
> Sent: 08 September 2020 09:13
> To: Simon Peyton Jones <simonpj at microsoft.com <mailto:simonpj at microsoft.com>>
> Cc: Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>>; Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>; ghc-steering-committee at haskell.org <mailto: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 <mailto: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 <mailto:bounces at haskell.org>> On Behalf Of Richard Eisenberg
> |  Sent: 02 September 2020 14:57
> |  To: Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>>
> |  Cc: ghc-steering-committee at haskell.org <mailto: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 <mailto: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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%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 <mailto:mail at 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0>%2F&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0>%7Cfa6e3a6bcdf
> |  04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
> |  &amp;reserved=0
> |  >>
> |  >>
> |  >> _______________________________________________
> |  >> ghc-steering-committee mailing list
> |  >> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> |  >
> |  > _______________________________________________
> |  > ghc-steering-committee mailing list
> |  > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0>%7Cfa6e3a6bcdf04ed5
> |  611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
> |  199468575&amp;sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
> |  amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%3D&reserved=0>
>  
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201002/60d6099b/attachment-0001.html>

From rae at richarde.dev  Fri Oct  2 19:06:04 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Fri, 2 Oct 2020 19:06:04 +0000
Subject: [ghc-steering-committee] Please review #281: Visible 'forall'
 in types of terms
In-Reply-To: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>
References: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>
Message-ID: <010f0174eab50054-a8f99357-de5c-4210-a7e4-8fae09c36fc0-000000@us-east-2.amazonses.com>

I'm in support of this proposal, but I've pushed back on a few softer points. I've commented on GitHub.

Richard

> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> Hello,
> 
> Proposal #281 is ready for review by the committee.   My recommendation is to accept it,  I've
> written a summary of my understanding to the proposal and my recommendation on the GitHub
> thread, accessible through these links:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://github.com/ghc-proposals/ghc-proposals/pull/281>
> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst>
> 
> Let the discussion begin!
> 
> -Iavor
> _______________________________________________
> 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/20201002/6daa6af0/attachment.html>

From trupill at gmail.com  Sun Oct  4 19:30:58 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sun, 4 Oct 2020 21:30:58 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>

Richard, I really liked your idea, so I've started to implement it as part
of the proposal. You can read the current version as
https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md.
TL;DR: extensions should fulfill as many criteria as possible, we use
another repo with one issue per extension.

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

Alejandro

El vie., 2 oct. 2020 a las 17:33, Richard Eisenberg (<rae at richarde.dev>)
escribió:

> A few scattered thoughts:
>
> * I don't see a particular need to debate on this list separately from a
> debate more in public. This list is public, anyway! And having the debate
> organized from as early as possible seems better.
>
> * I feel strongly that we should find a venue where we can discuss
> individual extensions on separately-marshalled threads, not in one
> monolithic clump. One idea (I think?) that was floated was to start a new
> repo (in the ghc-proposals org), where we can make a ticket for any
> contested extension. Kialo is another idea (assuming it supports separate
> threads for separate ideas); I have no experience. In the end, I don't care
> much about where this happens, as long as separate threads are indeed
> separable.
>
> * Debating the criteria seems like a worthy place to start. That *could*
> be done over email, but I think a proposal is better.
>
> Maybe this suggests the following structure:
>
> * A ghc-proposal that sets out the criteria for inclusion -- but does not
> opine on any extensions (except perhaps as illustrations of a criterion).
> This can get debated and accepted in the usual fashion, except that it
> might form a new document in the top level of our repo, not just another
> proposal. This initial proposal can also set out the way to stage the rest
> of the debate.
>
> * Upon acceptance, we proceed with the approach outlined in the first
> step, such as the extra repo or the Kialo space.
>
> * Profit.
>
> Richard
>
> On Oct 1, 2020, at 3:34 PM, Alejandro Serrano Mena <trupill at gmail.com>
> wrote:
>
> My idea was to turn the original wiki page
> https://github.com/ghc-proposals/ghc-proposals/wiki/GHC2020 into an
> actual proposal, so we can open it to discussion. Except for a few
> extensions, I copied the original acceptance list, since people seemed to
> mostly agree with them.
>
> In any case, the aim was to agree on some set of extensions that we could
> propose as a Committee, before opening to further consultation, especially
> in order to agree on a set of criteria. It could well be that we should
> refrain from adding some of them; it seems that you think that roles for
> example are not there yet, so we should remove any extension which uses
> them implicitly.
>
> I am happy to go back to the original thread you sent, and tell which are
> those extensions which I consider fine. But as you said, that would make
> the discussion terribly inefficient. Any thoughts on the approach to
> follow? Otherwise I feel we'll be forever in a sort of deadlock. I am also
> happy with taking Iavor's original list, turning it into a proposal, and
> let the community speak. But then we need a good story about why some
> common extensions, like MultiParamTypeClasses, are not included.
>
> Regards,
> Alejandro
>
> El jue., 1 oct. 2020 a las 18:10, Iavor Diatchki (<
> iavor.diatchki at gmail.com>) escribió:
>
>> I quite strongly disagree with a bunch of the classifications on
>> Alejandro's link but I have no idea *why* he thinks they match the
>> criteria, or what that even means.   Rather than having an unstructured
>> discussion about "I don't agree with this or that", I'd encourage us to
>> avoid the "big bang" approach, of having a page with all extensions, and do
>> something more focused.    For example, in the extensions I sent in the
>> original e-mail of this thread are grouped more or less "by topic", and I
>> think we should do something similar in the discussion.
>>
>> For the sake of concreteness, why don't we start by discussing extensions
>> related to Haskell's deriving mechanism? In Alejandro's current link there
>> are a whole lot of these listed as "matching all criteria", but not all of
>> them are compatible with each other, so they should not be all part of GHC
>> 2020. On this topic, the extensions I think should be part of GHC2020 would
>> be:
>>    1. EmptyDataDeriving
>>    2. StandaloneDeriving
>>    3. DeriveGeneric
>>    4. DeriveLift
>>
>> I don't think any of these are likely to affect existing code bases, and
>> I don't think listing them as an explicit extension gives you any
>> information that you couldn't easily obtain by just looking at the code.
>> I don't use (1) a lot but I think it makes the language more consistent.
>> (2) I use this sometimes, and having an extension to enable it doesn't
>> really add any extra information, and (3) and (4) are for Generics and
>> Template Haskell, both of which are fairly common and not likely to go away.
>>
>> Other extensions that I use quite often are `GeneralizedNewtypeDeriving`,
>> `DeriveTraversible`.  I don't think we should add
>> `GenerelizedNewtypeDeriving` because it brings in the whole "role"
>> annotation machinery.  I know why we need it at the moment, but it doesn't
>> seem particularly elegant.  I also tend to use it in extremely restricted
>> ways, mostly to derive `Monad` instances.   `DeriveTraversible` seems nice
>> and I do use it, but I think it potentially interferes with the other
>> deriving techniques (e.g. GND).
>>
>> -Iavor
>> PS: I'd be up for trying out something like Kialo if we'd prefer to use a
>> tool rather than having the discussion over e-mail
>>
>> On Thu, Oct 1, 2020 at 1:32 AM Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>>
>>> Thanks.  Rather than explaining to me, you could update the proposal?
>>> (In due course.)
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 01 October 2020 09:18
>>> *To:* Simon Peyton Jones <simonpj at microsoft.com>
>>> *Cc:* Iavor Diatchki <iavor.diatchki at gmail.com>; Richard Eisenberg <
>>> rae at richarde.dev>; ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> My idea is to make this a bit better before sending the PR to the
>>> ghc-proposals repo (as Iavor suggested), but any preliminary feedback is
>>> welcome.
>>>
>>>
>>>
>>> Answering your questions (maybe Richard can also explain a bit, I'm
>>> giving here my interpretation):
>>>
>>> - By "complementing" we mean a (mostly subjective) idea that it goes
>>> with the spirit of Haskell. For example, MultiParamTypeClasses extends
>>> what's already there, and works well with the rest of features. If we
>>> suddenly decided you can use Lisp-like syntax, that would not complement
>>> it's current design.
>>>
>>> - We want to keep all potentially unsafe features under flags.
>>> IncoherentInstances should not be enabled by default because of its
>>> behavior.
>>>
>>> - I prefer to have a strict wording and then add exceptions. So I would
>>> say conservativeness should be described as "no program ceases to be
>>> accepted".
>>>
>>> - "Failure mode" is again not concrete, but the idea is that everything
>>> which would make the developer experience worse by being enabled should not
>>> be part of GHC2020.
>>>
>>>
>>>
>>> El jue., 1 oct. 2020 a las 10:11, Simon Peyton Jones (<
>>> simonpj at microsoft.com>) escribió:
>>>
>>> Thanks Alejandro. How do you want feedback?  The “discussed at this PR”
>>> link is broken.
>>>
>>>
>>>
>>> I think the criteria could be tightened up quite a bit.
>>>
>>>
>>>
>>>    - I don’t know what “The extensions *complement* the design of
>>>    standard Haskell” means.   What would be an example of something that
>>>    doesn’t complement it?
>>>
>>>
>>>
>>>    - I don’t know what “The extension is *not* to *gate-keep* an
>>>    advanced or potentially-unsafe feature” means.
>>>
>>>
>>>
>>>    - Item (1), conservative extension, is a bit ambiguous. Is says
>>>    “Mostly” but then “all programs”.  Which is your intent?
>>>
>>>
>>>
>>>    - What is a “new failure mode”?  Do you mean existing programs that
>>>    fail when the extension is on?  Or new programs that are trying to use the
>>>    new extension but get it wrong?   For the latter it’s hard to see how
>>>    they’d be rare.
>>>
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:* Alejandro Serrano Mena <trupill at gmail.com>
>>> *Sent:* 30 September 2020 21:06
>>> *To:* Iavor Diatchki <iavor.diatchki at gmail.com>
>>> *Cc:* Simon Peyton Jones <simonpj at microsoft.com>; Richard Eisenberg <
>>> rae at richarde.dev>; ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 2020
>>>
>>>
>>>
>>> Dear all,
>>>
>>> I've started working on a proposal for GHC2020. You can see the current
>>> status here:
>>> https://github.com/serras/ghc-proposals/blob/ghc-2020/proposals/0000-ghc-2020.md
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fserras%2Fghc-proposals%2Fblob%2Fghc-2020%2Fproposals%2F0000-ghc-2020.md&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=1rK336YRHSWotXYZAqkH4Iwwi7efswXe5jTplbPu1Bs%3D&reserved=0>
>>>
>>>
>>>
>>> I noticed the list by Richard was not exhaustive. Those extensions are
>>> headed by "In discussion". Preferably we should make up our minds before
>>> presenting the proposal. I would say there are three big groups of
>>> proposals. Any feedback is welcome on that part.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Alejandrp
>>>
>>>
>>>
>>> El mar., 29 sept. 2020 a las 18:38, Iavor Diatchki (<
>>> iavor.diatchki at gmail.com>) escribió:
>>>
>>> Thanks Alejandro.  My preference would be that you share whatever you
>>> come up with the list so we can discuss it, before making a proposal that
>>> would represent the committee.
>>>
>>> -Iavor
>>>
>>>
>>>
>>> On Tue, Sep 29, 2020 at 9:07 AM Simon Peyton Jones via
>>> ghc-steering-committee <ghc-steering-committee at haskell.org> wrote:
>>>
>>> OK by me.   Thank you
>>>
>>>
>>> Simon
>>>
>>>
>>>
>>> *From:* ghc-steering-committee <
>>> ghc-steering-committee-bounces at haskell.org> *On Behalf Of *Alejandro
>>> Serrano Mena
>>> *Sent:* 29 September 2020 15:51
>>> *To:* Richard Eisenberg <rae at richarde.dev>
>>> *Cc:* ghc-steering-committee at haskell.org
>>> *Subject:* Re: [ghc-steering-committee] GHC 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
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fwiki%2FGHC2020&data=02%7C01%7Csimonpj%40microsoft.com%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977231780&sdata=lpOFIx5mBcaUbKIDIhs%2BnAmYd72%2FctVTwij1WJYTVF8%3D&reserved=0>
>>>
>>>
>>>
>>> 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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977241774&sdata=71oNkM1l%2BSDf%2BAbWVDFSMGQrC3tu4ty%2FQ2M47lOnmu4%3D&reserved=0>
>>> %2F&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=ddj4e3mS%2F%2FAhpGbMV5NkneCJW1aXe1YKfM4hg0%2FwGNg%3D&reserved=0>
>>> %7Cfa6e3a6bcdf
>>> |
>>> 04ed5611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>>> |
>>> 46518199468575&amp;sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%3D&reserved=0>
>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>> |  committee&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%3D&reserved=0>
>>> %7Cfa6e3a6bcdf04ed5
>>> |
>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>> |
>>> 199468575&amp;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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=hFTP2bNd5ZWcDQ0vH98O3hhwYOp%2BIV0iLwHMTBJZEHI%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
>>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
>>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977291746&sdata=EGhYP0xZU5J21J4Yw3G7kdxbEhIqCraDAK8JOCnCIOw%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
>>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
>>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977301742&sdata=BDMtmTuVxULHpG1ud5cNYDbaOKsami7UeJito%2FRgNZs%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
>>> <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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977311737&sdata=p895UWSa99PCifyQgpA9WEZKtdgVz4LbPW9y3TCE5%2Bc%3D&reserved=0>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201004/0e740d38/attachment-0001.html>

From mail at joachim-breitner.de  Sun Oct  4 21:13:55 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 04 Oct 2020 23:13:55 +0200
Subject: [ghc-steering-committee] Please review #367: Clarify primops using
 unboxed sums, Shepherd: Simon Marlow
Message-ID: <50e635bf8c9a58568aa810fc284da4cdf39ce702.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Clarify primops using unboxed sum
has been proposed by David Feuer
https://github.com/ghc-proposals/ghc-proposals/pull/367
https://github.com/treeowl/ghc-proposals/blob/unboxed-sum-primops/proposals/0000-unboxed-sum-primops.md

I’ll propose Simon Marlow as the shepherd.

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

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



From david.feuer at gmail.com  Fri Oct  9 15:06:34 2020
From: david.feuer at gmail.com (David Feuer)
Date: Fri, 9 Oct 2020 11:06:34 -0400
Subject: [ghc-steering-committee] List archive failure
Message-ID: <CAMgWh9ufqLEmyLsL2qdZKh+-3zmHmU+iyk2Su14E4kYNNTSntQ@mail.gmail.com>

There was a serious problem on haskell.org leading to a failure to archive
several days of mailing list messages. As I am not subscribed to this list,
I would appreciate if someone could let me know what, if any, messages have
been sent about proposal #367 since the initial request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201009/d36dff45/attachment.html>

From eric at seidel.io  Fri Oct  9 15:44:21 2020
From: eric at seidel.io (Eric Seidel)
Date: Fri, 09 Oct 2020 11:44:21 -0400
Subject: [ghc-steering-committee] List archive failure
In-Reply-To: <CAMgWh9ufqLEmyLsL2qdZKh+-3zmHmU+iyk2Su14E4kYNNTSntQ@mail.gmail.com>
References: <CAMgWh9ufqLEmyLsL2qdZKh+-3zmHmU+iyk2Su14E4kYNNTSntQ@mail.gmail.com>
Message-ID: <b9c73af7-ea5e-47b6-a1b3-051103c80983@www.fastmail.com>

Hi David, I have not seen any traffic about #367 since the proposal was assigned to Simon M. The list is usually pretty quiet about proposals until the shepherd has made their initial recommendation, which would also be posted to GitHub.

On Fri, Oct 9, 2020, at 11:06, David Feuer wrote:
> There was a serious problem on haskell.org leading to a failure to 
> archive several days of mailing list messages. As I am not subscribed 
> to this list, I would appreciate if someone could let me know what, if 
> any, messages have been sent about proposal #367 since the initial 
> request.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From mail at joachim-breitner.de  Mon Oct 12 08:42:45 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 12 Oct 2020 10:42:45 +0200
Subject: [ghc-steering-committee] #364: Unify Nat and Natural,
 recommendation: accept
In-Reply-To: <CALpVSmN9h4-H8Xw8ic4gmO2MNZJaQOSK7OAzMY82Qo5HfHaD4g@mail.gmail.com>
References: <fcdc613a96c05b7c18b7f0fb88ae53d2035bba45.camel@joachim-breitner.de>
 <CAHnFXOtHGNTyaQ=bK-gZqq6bqLZggRvy85r8XEsxKN28UpXhJw@mail.gmail.com>
 <CALpVSmN9h4-H8Xw8ic4gmO2MNZJaQOSK7OAzMY82Qo5HfHaD4g@mail.gmail.com>
Message-ID: <376359084e355709c9e97012fe279b13313fc7bc.camel@joachim-breitner.de>

Hi

great, looks like we are all in agreement. accepted.

Cheers,
Joachim

Am Freitag, den 02.10.2020, 14:47 +0300 schrieb Vitaly Bragilevsky:
> Hi, 
> 
> I support the recommendation to accept this proposal. 
> 
> Vitaly
> 
> чт, 1 окт. 2020 г. в 13:02, Alejandro Serrano Mena <trupill at gmail.com>:
> > Dear all,
> > I recommend that we accept this proposal. The only problematic (read, not backwards-compatible) bit is the case of a type class having instances for both `Nat` and `Natural`, but that seems very unlikely.
> > 
> > Something which I thought about was whether any of `Nat` or `Natural` were implementing something akin to Peano naturals (so we could have inductive instances working on Zero and (Succ n)), both none of both do, so the alignment seems correct to me.
> > 
> > Regards,
> > Alejandro
> > 
> > El vie., 25 sept. 2020 a las 16:06, Joachim Breitner (<mail at joachim-breitner.de>) escribió:
> > > Dear Committee,
> > > 
> > > this is your secretary speaking:
> > > 
> > > Unify Nat and Natural
> > > has been proposed by Richard
> > > https://github.com/ghc-proposals/ghc-proposals/pull/364
> > > https://github.com/goldfirere/ghc-proposals/blob/natural/proposals/0000-unify-natural.rst
> > > 
> > > I’ll propose Alejandro as the shepherd.
> > > 
> > > Please guide us to a conclusion as outlined in 
> > > https://github.com/ghc-proposals/ghc-proposals#committee-process
> > > 
> > > Thanks,
> > > Joachim
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > ghc-steering-committee at haskell.org
> > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From arnaud.spiwack at tweag.io  Tue Oct 13 07:37:13 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Tue, 13 Oct 2020 09:37:13 +0200
Subject: [ghc-steering-committee] Please review #281: Visible 'forall'
 in types of terms
In-Reply-To: <CAGK9nuqzdpcknceMGnhZ-imKAOhLdq7i7s6rHtHvarj=Zn-_5A@mail.gmail.com>
References: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>
 <010f0174eab50054-a8f99357-de5c-4210-a7e4-8fae09c36fc0-000000@us-east-2.amazonses.com>
 <CANsrgP+wcVemJW0PUF2RwfHjqD5ErNV94+sCC64FeqRgd_=uhA@mail.gmail.com>
 <CAGK9nuqzdpcknceMGnhZ-imKAOhLdq7i7s6rHtHvarj=Zn-_5A@mail.gmail.com>
Message-ID: <CAH6fHQkzoVyxwRhd8wGoJVvPySUaYRdMTY210P4Va7C44DADuw@mail.gmail.com>

There has been conversation to this effect on the Github PR, for a day or
so, starting at
https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033510
.

But I wanted to point out that there are really two, interlocked, yet
distinct, parts in this proposal.
1. Having a `forall a ->` construct for types of terms
2. How is `f blah` parsed if `f` has type `forall a -> …`?

I am definitely sympathetic to (1). As much as I like my `f @…`s I am bound
to admit that it produces error messages from the 7th Circle of Hell. And,
since it's a very useful pattern, making it "official" is rather neat a
plan on paper.

But (2) is very very difficult, because we have really two grammars at play
here: the grammar for term, and the grammar for types (I'll conflate
grammar and name resolution in the following). In the `f @…` style, we
switch to the type grammar to parse whatever's in the `@`. But if we want
to to write type applications in the `forall a->` case as `f a`, then we
sort of have to parse `a` as a term (though there is some leeway in name
resolution). And that introduces all sorts of potentially weird behaviour
(see the link above for a good documentation of what). Part of the
difficulty, I should stress, is that, in types the apostrophe `'` means:
I'm speaking of a data constructor, not a type constructor. Whereas in
terms, it means: I'm opening a Template Haskell slice.

Part of the impetus for the proposal actually going in the direction of
parsing the type argument as a term, is the desire to eventually merge the
terms and types grammars. I don't know how widespread this desire actually
is (maybe this is something we should speak about). In my personal opinion,
it's not a very plausibly achievable goal, nor is it particularly necessary
for dependent types. (It does, of course, have a number of advantages,
which is why Coq, Agda, and Idris do have a single grammar indeed).

I think that I'd be happier if we had a sigil to switch between the type
grammar and the term grammar. But, here, the issue is that nice sigils are
harder and harder to come by.

My point, though, is that while this proposal may look like it has a small
scope, it actually is a fairly large and intricate proposal, and requires
quite a bit of attention.

/Arnaud

On Mon, Oct 5, 2020 at 7:25 PM Iavor Diatchki <iavor.diatchki at gmail.com>
wrote:

> I've been following the discussion and I think we should keep it in the
> "committee review" phase because
>    1. The discussion is due to questions from the committee members, and
>    2. Even though it seems like a lot, mostly it's been along the lines of
> clarification and better phrasing of things, rather than big changes to the
> proposal
>
> I don't feel strongly about it, so if others also think we should move it
> to the discussion phase, I'd be happy to do so, I just don't want to loose
> the steam we seem to have gathered :)
>
> Let me know,
> -Iavor
>
>
> On Mon, Oct 5, 2020 at 2:38 AM Simon Marlow <marlowsd at gmail.com> wrote:
>
>> There seems to have been a lot of ensuing discussion on this one, should
>> it go back into the discussion phase?
>>
>> On Fri, 2 Oct 2020 at 20:06, Richard Eisenberg <rae at richarde.dev> wrote:
>>
>>> I'm in support of this proposal, but I've pushed back on a few softer
>>> points. I've commented on GitHub.
>>>
>>> Richard
>>>
>>> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>> wrote:
>>>
>>> Hello,
>>>
>>> Proposal #281 is ready for review by the committee.   My recommendation
>>> is to accept it,  I've
>>> written a summary of my understanding to the proposal and my
>>> recommendation on the GitHub
>>> thread, accessible through these links:
>>>
>>> https://github.com/ghc-proposals/ghc-proposals/pull/281
>>>
>>> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst
>>>
>>> Let the discussion begin!
>>>
>>> -Iavor
>>> _______________________________________________
>>> 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/20201013/b437be3f/attachment.html>

From arnaud.spiwack at tweag.io  Wed Oct 14 14:08:03 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 14 Oct 2020 16:08:03 +0200
Subject: [ghc-steering-committee] #283: Local modules, recommendation: accept
Message-ID: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>

Dear all,

I would like to bring our own Richard Eisenberg’s proposal, #283: Local
modules, to your attention.
https://github.com/ghc-proposals/ghc-proposals/pull/283

The proposal is an attempt at solving the long debated issue that we can’t
export qualified names out of a module (*e.g.* we may have to repeat import
qualified Data.Map as Map and import qualified Data.Set as Set in every
module in a project, rather than simply calling import MyPrelude which
would take care of both and more), to improve scope management, and sharing
names between types in the same files, while making namespaces more
convenient to use in the process.

It’s a pretty ambitious proposal, with quite a few interlocking pieces.
Yet, in my opinion, they fit pretty well together. And I’m, as a potential
consumer, very enthusiastic about it.

Some highlight (though do read the whole thing):

   - We can define modules inside of other modules, with the syntax module
   Foo (some, optional, exports) where …
   - Like in the rest of Haskell, modules are no more than namespaces.
   Therefore you can open two module Foo, it will just merge the names in
   them
   - Values in local modules can be referred to, qualified, in the
   encompassing module
   - Local modules can be exported, importing them will import the name as
   qualified
   - A new import module Foo statement can be used in let and where
   clauses, it brings everything of the form Foo.x into scope unqualified
   for the scope of the let or where

Additionally, there is a small point that is not integral to the rest of
the proposal, where defining, say, a type

data T
  = A
  | B

Would create a local module named T, such that the constructors could be
referred to as T.A and T.B. I mention it separately, because it causes the
only (small) backward incompatibility (that is Haskell 2010 programs which
stop compiling when you turn on -XLocalModules).

I’m rather in favour of keeping it in, but it’s worth mentioning.

I pretty much want all of these features in my daily programming, so, as I
said above, I’m very enthusiastic for all of this. And I’m pretty happy
with the realisation. Hence my recommending acceptance.

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

From iavor.diatchki at gmail.com  Thu Oct 15 15:41:36 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Thu, 15 Oct 2020 08:41:36 -0700
Subject: [ghc-steering-committee] Please review #281: Visible 'forall'
 in types of terms
In-Reply-To: <CAH6fHQkzoVyxwRhd8wGoJVvPySUaYRdMTY210P4Va7C44DADuw@mail.gmail.com>
References: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>
 <010f0174eab50054-a8f99357-de5c-4210-a7e4-8fae09c36fc0-000000@us-east-2.amazonses.com>
 <CANsrgP+wcVemJW0PUF2RwfHjqD5ErNV94+sCC64FeqRgd_=uhA@mail.gmail.com>
 <CAGK9nuqzdpcknceMGnhZ-imKAOhLdq7i7s6rHtHvarj=Zn-_5A@mail.gmail.com>
 <CAH6fHQkzoVyxwRhd8wGoJVvPySUaYRdMTY210P4Va7C44DADuw@mail.gmail.com>
Message-ID: <CAGK9nup8oyMvhHivvcqQWuOs_TzsL5QutSMi7JWqTu4jVJn3PA@mail.gmail.com>

I agree with Arnaud's observations.

It seems that the discussion on this proposal is not converging toward a
solution, and now more folks from the community have jumped in, so my
inclination would be to move this proposal back to the "needs revision"
phase as Simon M suggested earlier.
Thoughts?

-Iavor

On Tue, Oct 13, 2020 at 12:37 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> There has been conversation to this effect on the Github PR, for a day or
> so, starting at
> https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033510
> .
>
> But I wanted to point out that there are really two, interlocked, yet
> distinct, parts in this proposal.
> 1. Having a `forall a ->` construct for types of terms
> 2. How is `f blah` parsed if `f` has type `forall a -> …`?
>
> I am definitely sympathetic to (1). As much as I like my `f @…`s I am
> bound to admit that it produces error messages from the 7th Circle of Hell.
> And, since it's a very useful pattern, making it "official" is rather neat
> a plan on paper.
>
> But (2) is very very difficult, because we have really two grammars at
> play here: the grammar for term, and the grammar for types (I'll conflate
> grammar and name resolution in the following). In the `f @…` style, we
> switch to the type grammar to parse whatever's in the `@`. But if we want
> to to write type applications in the `forall a->` case as `f a`, then we
> sort of have to parse `a` as a term (though there is some leeway in name
> resolution). And that introduces all sorts of potentially weird behaviour
> (see the link above for a good documentation of what). Part of the
> difficulty, I should stress, is that, in types the apostrophe `'` means:
> I'm speaking of a data constructor, not a type constructor. Whereas in
> terms, it means: I'm opening a Template Haskell slice.
>
> Part of the impetus for the proposal actually going in the direction of
> parsing the type argument as a term, is the desire to eventually merge the
> terms and types grammars. I don't know how widespread this desire actually
> is (maybe this is something we should speak about). In my personal opinion,
> it's not a very plausibly achievable goal, nor is it particularly necessary
> for dependent types. (It does, of course, have a number of advantages,
> which is why Coq, Agda, and Idris do have a single grammar indeed).
>
> I think that I'd be happier if we had a sigil to switch between the type
> grammar and the term grammar. But, here, the issue is that nice sigils are
> harder and harder to come by.
>
> My point, though, is that while this proposal may look like it has a small
> scope, it actually is a fairly large and intricate proposal, and requires
> quite a bit of attention.
>
> /Arnaud
>
> On Mon, Oct 5, 2020 at 7:25 PM Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
>> I've been following the discussion and I think we should keep it in the
>> "committee review" phase because
>>    1. The discussion is due to questions from the committee members, and
>>    2. Even though it seems like a lot, mostly it's been along the lines
>> of clarification and better phrasing of things, rather than big changes to
>> the proposal
>>
>> I don't feel strongly about it, so if others also think we should move it
>> to the discussion phase, I'd be happy to do so, I just don't want to loose
>> the steam we seem to have gathered :)
>>
>> Let me know,
>> -Iavor
>>
>>
>> On Mon, Oct 5, 2020 at 2:38 AM Simon Marlow <marlowsd at gmail.com> wrote:
>>
>>> There seems to have been a lot of ensuing discussion on this one, should
>>> it go back into the discussion phase?
>>>
>>> On Fri, 2 Oct 2020 at 20:06, Richard Eisenberg <rae at richarde.dev> wrote:
>>>
>>>> I'm in support of this proposal, but I've pushed back on a few softer
>>>> points. I've commented on GitHub.
>>>>
>>>> Richard
>>>>
>>>> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
>>>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Proposal #281 is ready for review by the committee.   My recommendation
>>>> is to accept it,  I've
>>>> written a summary of my understanding to the proposal and my
>>>> recommendation on the GitHub
>>>> thread, accessible through these links:
>>>>
>>>> https://github.com/ghc-proposals/ghc-proposals/pull/281
>>>>
>>>> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst
>>>>
>>>> Let the discussion begin!
>>>>
>>>> -Iavor
>>>> _______________________________________________
>>>> 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/20201015/b9fd5e11/attachment.html>

From rae at richarde.dev  Thu Oct 15 15:54:52 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 15 Oct 2020 15:54:52 +0000
Subject: [ghc-steering-committee] Please review #281: Visible 'forall'
 in types of terms
In-Reply-To: <CAGK9nup8oyMvhHivvcqQWuOs_TzsL5QutSMi7JWqTu4jVJn3PA@mail.gmail.com>
References: <CAGK9nuoK-Yo_=QM=sHXoD3957pAB=5D8tmpJ8DrtZBUaBN8B-Q@mail.gmail.com>
 <010f0174eab50054-a8f99357-de5c-4210-a7e4-8fae09c36fc0-000000@us-east-2.amazonses.com>
 <CANsrgP+wcVemJW0PUF2RwfHjqD5ErNV94+sCC64FeqRgd_=uhA@mail.gmail.com>
 <CAGK9nuqzdpcknceMGnhZ-imKAOhLdq7i7s6rHtHvarj=Zn-_5A@mail.gmail.com>
 <CAH6fHQkzoVyxwRhd8wGoJVvPySUaYRdMTY210P4Va7C44DADuw@mail.gmail.com>
 <CAGK9nup8oyMvhHivvcqQWuOs_TzsL5QutSMi7JWqTu4jVJn3PA@mail.gmail.com>
Message-ID: <010f01752cf89e8a-2f692bf1-b1b1-4938-9173-429630929915-000000@us-east-2.amazonses.com>

Yes, I think this proposal meets the criteria of "needs revision" -- if at least to clarify all the points that have been raised.

> On Oct 15, 2020, at 11:41 AM, Iavor Diatchki <iavor.diatchki at gmail.com> wrote:
> 
> I agree with Arnaud's observations.
> 
> It seems that the discussion on this proposal is not converging toward a solution, and now more folks from the community have jumped in, so my inclination would be to move this proposal back to the "needs revision" phase as Simon M suggested earlier.
> Thoughts?
> 
> -Iavor
> 
> On Tue, Oct 13, 2020 at 12:37 AM Spiwack, Arnaud <arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>> wrote:
> There has been conversation to this effect on the Github PR, for a day or so, starting at https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033510 <https://github.com/ghc-proposals/ghc-proposals/pull/281#issuecomment-707033510> .
> 
> But I wanted to point out that there are really two, interlocked, yet distinct, parts in this proposal.
> 1. Having a `forall a ->` construct for types of terms
> 2. How is `f blah` parsed if `f` has type `forall a -> …`?
> 
> I am definitely sympathetic to (1). As much as I like my `f @…`s I am bound to admit that it produces error messages from the 7th Circle of Hell. And, since it's a very useful pattern, making it "official" is rather neat a plan on paper.
> 
> But (2) is very very difficult, because we have really two grammars at play here: the grammar for term, and the grammar for types (I'll conflate grammar and name resolution in the following). In the `f @…` style, we switch to the type grammar to parse whatever's in the `@`. But if we want to to write type applications in the `forall a->` case as `f a`, then we sort of have to parse `a` as a term (though there is some leeway in name resolution). And that introduces all sorts of potentially weird behaviour (see the link above for a good documentation of what). Part of the difficulty, I should stress, is that, in types the apostrophe `'` means: I'm speaking of a data constructor, not a type constructor. Whereas in terms, it means: I'm opening a Template Haskell slice.
> 
> Part of the impetus for the proposal actually going in the direction of parsing the type argument as a term, is the desire to eventually merge the terms and types grammars. I don't know how widespread this desire actually is (maybe this is something we should speak about). In my personal opinion, it's not a very plausibly achievable goal, nor is it particularly necessary for dependent types. (It does, of course, have a number of advantages, which is why Coq, Agda, and Idris do have a single grammar indeed).
> 
> I think that I'd be happier if we had a sigil to switch between the type grammar and the term grammar. But, here, the issue is that nice sigils are harder and harder to come by.
> 
> My point, though, is that while this proposal may look like it has a small scope, it actually is a fairly large and intricate proposal, and requires quite a bit of attention.
> 
> /Arnaud
> 
> On Mon, Oct 5, 2020 at 7:25 PM Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
> I've been following the discussion and I think we should keep it in the "committee review" phase because
>    1. The discussion is due to questions from the committee members, and 
>    2. Even though it seems like a lot, mostly it's been along the lines of clarification and better phrasing of things, rather than big changes to the proposal
> 
> I don't feel strongly about it, so if others also think we should move it to the discussion phase, I'd be happy to do so, I just don't want to loose the steam we seem to have gathered :)
> 
> Let me know,
> -Iavor
> 
> 
> On Mon, Oct 5, 2020 at 2:38 AM Simon Marlow <marlowsd at gmail.com <mailto:marlowsd at gmail.com>> wrote:
> There seems to have been a lot of ensuing discussion on this one, should it go back into the discussion phase?
> 
> On Fri, 2 Oct 2020 at 20:06, Richard Eisenberg <rae at richarde.dev <mailto:rae at richarde.dev>> wrote:
> I'm in support of this proposal, but I've pushed back on a few softer points. I've commented on GitHub.
> 
> Richard
> 
>> On Oct 1, 2020, at 1:07 PM, Iavor Diatchki <iavor.diatchki at gmail.com <mailto:iavor.diatchki at gmail.com>> wrote:
>> 
>> Hello,
>> 
>> Proposal #281 is ready for review by the committee.   My recommendation is to accept it,  I've
>> written a summary of my understanding to the proposal and my recommendation on the GitHub
>> thread, accessible through these links:
>> 
>> https://github.com/ghc-proposals/ghc-proposals/pull/281 <https://github.com/ghc-proposals/ghc-proposals/pull/281>
>> https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst <https://github.com/int-index/ghc-proposals/blob/visible-forall/proposals/0000-visible-forall.rst>
>> 
>> Let the discussion begin!
>> 
>> -Iavor
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From mail at joachim-breitner.de  Thu Oct 15 16:33:27 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 15 Oct 2020 18:33:27 +0200
Subject: [ghc-steering-committee] #283: Local modules,
 recommendation: accept
In-Reply-To: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
Message-ID: <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de>

Hi,

very well written proposal, the motivation section is exemplary. In
particular excited about the ability to locally open a module
(something that I began to like when writing Ocaml).



> Would it be equivalent to say that all traditional import 
> declarations create local modules?

When reading the proposal, that was somehow automatically my mental
model. So I hope it is true, and that we can explain things this way.

This would actually rule out the alternative
> Drop point (8) allowing extension of existing local modules.
because `import qualified Foo as A; import qualified Bar as A` only
works if local modules can be extended. 



> Should -XLocalModules be required to import a local module?

My gut feeling is yes. The knowledge that `Foo.Bar.baz` comes from an
imported `Foo.Bar` should still be applicable, unless a language
extension clearly tells you that something is different.


So I am supportive. I could understand if someone argued “too big of a
change for too little impact; makes Haskell more complicated” … but I won’t be that someone.


Cheers,
Joachim

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



From arnaud.spiwack at tweag.io  Thu Oct 15 18:08:30 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Thu, 15 Oct 2020 20:08:30 +0200
Subject: [ghc-steering-committee] #283: Local modules,
	recommendation: accept
In-Reply-To: <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
 <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de>
Message-ID: <CAH6fHQn=ZTg02vOohJV3nXgf845_UjV17ifNOXQC=DzSpt8VkA@mail.gmail.com>

> In
> particular excited about the ability to locally open a module
> (something that I began to like when writing Ocaml).
>

It is also one of my favourite features in Ocaml. It's a fairly recent
addition to Ocaml (10ish years ago, I would say?), and I believe it's fair
to say that it had a profound impact on coding style throughout the
community. For the better in my opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201015/947c101d/attachment.html>

From marlowsd at gmail.com  Fri Oct 16 09:03:27 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 16 Oct 2020 10:03:27 +0100
Subject: [ghc-steering-committee] #283: Local modules,
	recommendation: accept
In-Reply-To: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
Message-ID: <CANsrgPJ6WvnjcSjhfiZPzDX1UMmBNWku5X2V6APyya4OE1ADJQ@mail.gmail.com>

I like the proposal. Particularly I like that "it's just namespacing", you
can explain everything in terms of what entities are in scope with what
names.

But one thing jars with me:

* In existing import statements, names are made available both qualified
and unqualified unless you say "qualified", in which case only the
qualified names are brought into scope.
* In this proposal, the "qualified" convention is extended to data/class/..
declarations, and to module exports. That's all fine.
* However, local modules use a different convention: you get only the
qualified names by default unless you add the "import" keyword to bring
into scope the unqualified names. This applies both to a local module
declaration at the top level, and to the import of a local module in an
import list.

Why the inconsistency here? Can't we use the "qualified" convention
everywhere? I think I would rather prefer to write

   qualified module M (x,y) where ...

to make it clear that you have to refer to M.x qualified. That's a lot more
consistent with import statements.

Perhaps the concern is that if you just "import M" and M contains local
modules, we want those modules to be imported qualified by default. But we
could just state that to be the case, so that you have to explicitly
"import M (module N)" to bring N's entities into scope unqualified.

Cheers
Simon


On Wed, 14 Oct 2020 at 15:08, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> I would like to bring our own Richard Eisenberg’s proposal, #283: Local
> modules, to your attention.
> https://github.com/ghc-proposals/ghc-proposals/pull/283
>
> The proposal is an attempt at solving the long debated issue that we can’t
> export qualified names out of a module (*e.g.* we may have to repeat import
> qualified Data.Map as Map and import qualified Data.Set as Set in every
> module in a project, rather than simply calling import MyPrelude which
> would take care of both and more), to improve scope management, and sharing
> names between types in the same files, while making namespaces more
> convenient to use in the process.
>
> It’s a pretty ambitious proposal, with quite a few interlocking pieces.
> Yet, in my opinion, they fit pretty well together. And I’m, as a potential
> consumer, very enthusiastic about it.
>
> Some highlight (though do read the whole thing):
>
>    - We can define modules inside of other modules, with the syntax module
>    Foo (some, optional, exports) where …
>    - Like in the rest of Haskell, modules are no more than namespaces.
>    Therefore you can open two module Foo, it will just merge the names in
>    them
>    - Values in local modules can be referred to, qualified, in the
>    encompassing module
>    - Local modules can be exported, importing them will import the name
>    as qualified
>    - A new import module Foo statement can be used in let and where
>    clauses, it brings everything of the form Foo.x into scope unqualified
>    for the scope of the let or where
>
> Additionally, there is a small point that is not integral to the rest of
> the proposal, where defining, say, a type
>
> data T
>   = A
>   | B
>
> Would create a local module named T, such that the constructors could be
> referred to as T.A and T.B. I mention it separately, because it causes
> the only (small) backward incompatibility (that is Haskell 2010 programs
> which stop compiling when you turn on -XLocalModules).
>
> I’m rather in favour of keeping it in, but it’s worth mentioning.
>
> I pretty much want all of these features in my daily programming, so, as I
> said above, I’m very enthusiastic for all of this. And I’m pretty happy
> with the realisation. Hence my recommending acceptance.
>
> /Arnaud
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201016/94a9a6e3/attachment-0001.html>

From trupill at gmail.com  Sat Oct 17 19:26:30 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 17 Oct 2020 21:26:30 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
Message-ID: <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>

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-2020.md

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 at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201017/5cfc0ab1/attachment.html>

From trupill at gmail.com  Sat Oct 17 19:32:57 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Sat, 17 Oct 2020 21:32:57 +0200
Subject: [ghc-steering-committee] #283: Local modules,
	recommendation: accept
In-Reply-To: <CAH6fHQn=ZTg02vOohJV3nXgf845_UjV17ifNOXQC=DzSpt8VkA@mail.gmail.com>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
 <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de>
 <CAH6fHQn=ZTg02vOohJV3nXgf845_UjV17ifNOXQC=DzSpt8VkA@mail.gmail.com>
Message-ID: <CAHnFXOvzoxfRyViB3TcvwrQTOR1WQPwM=K=i3PQdDgAXshMwpQ@mail.gmail.com>

I like the proposal as it stands.

El jue., 15 oct. 2020 a las 20:09, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
escribió:

>
> In
>> particular excited about the ability to locally open a module
>> (something that I began to like when writing Ocaml).
>>
>
> It is also one of my favourite features in Ocaml. It's a fairly recent
> addition to Ocaml (10ish years ago, I would say?), and I believe it's fair
> to say that it had a profound impact on coding style throughout the
> community. For the better in my opinion.
> _______________________________________________
> 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/20201017/4156ff06/attachment.html>

From mail at joachim-breitner.de  Sun Oct 18 21:00:54 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Sun, 18 Oct 2020 23:00:54 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
Message-ID: <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>

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-2020.md


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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Mon Oct 19 07:21:57 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 19 Oct 2020 07:21:57 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 18 October 2020 22:01
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd069
|  9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681
|  5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
|  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
|  pFwJB8wvBxWULqIqFes%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
|  achim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d8096
|  44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
|  86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
|  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3csJZH2Ux30FM4OIpLb
|  QubZ0lVmz93H8j3Ko1X%2FOTaM%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd0
|  699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516
|  815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
|  CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SpEo1OwwBHDb7uIlkgBrnKbL
|  QKwKyWug5dv9Y5coJcQ%3D&amp;reserved=0

From trupill at gmail.com  Mon Oct 19 13:21:59 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 19 Oct 2020 15:21:59 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>

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 (<ghc-steering-committee at 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 <ghc-steering-committee-
> |  bounces at haskell.org> On Behalf Of Joachim Breitner
> |  Sent: 18 October 2020 22:01
> |  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd069
> |  9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681
> |  5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> |  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
> |  pFwJB8wvBxWULqIqFes%3D&amp;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 at joachim-breitner.de
> |
> |  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
> |  achim-
> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d8096
> |  44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> |  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3csJZH2Ux30FM4OIpLb
> |  QubZ0lVmz93H8j3Ko1X%2FOTaM%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cbdddd9d809644bd0
> |  699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516
> |  815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> |  CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SpEo1OwwBHDb7uIlkgBrnKbL
> |  QKwKyWug5dv9Y5coJcQ%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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201019/a635c488/attachment.html>

From simonpj at microsoft.com  Mon Oct 19 13:33:39 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Mon, 19 Oct 2020 13:33:39 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
Message-ID: <VI1PR83MB042956727E97D7809DE57D44AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

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 <trupill at gmail.com>
Sent: 19 October 2020 14:22
To: Simon Peyton Jones <simonpj at microsoft.com>
Cc: Joachim Breitner <mail at joachim-breitner.de>; ghc-steering-committee at 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 (<ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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 <ghc-steering-committee-
|  bounces at haskell.org<mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
|  Sent: 18 October 2020 22:01
|  To: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at 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<https://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&amp;data=04%7C01%7Csimonpj%40microsoft.com<https://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&amp;sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
|  pFwJB8wvBxWULqIqFes%3D&amp;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 at joachim-breitner.de<mailto: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=04%7C01%7Csimonpj%40microsoft.com%7Cde7ecf2a1a9147defe9808d87431fd49%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387105337593959%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B46NEAsMyMKCVVFIPYXoD2aqdUpqEGDAZaQEgt5BFq0%3D&reserved=0>%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com<https://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&amp;sdata=3csJZH2Ux30FM4OIpLb
|  QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&amp;reserved=0
|
|
|  _______________________________________________
|  ghc-steering-committee mailing list
|  ghc-steering-committee at haskell.org<mailto: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=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&amp;data=04%7C01%7Csimonpj%40microsoft.com<https://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&amp;sdata=SpEo1OwwBHDb7uIlkgBrnKbL
|  QKwKyWug5dv9Y5coJcQ%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201019/4cdabc57/attachment-0001.html>

From mail at joachim-breitner.de  Mon Oct 19 13:40:27 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Oct 2020 15:40:27 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
Message-ID: <3873f800c61946aa579b656e0910ad1e0c4073d3.camel@joachim-breitner.de>

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_excite_you/

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Mon Oct 19 13:43:38 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Oct 2020 15:43:38 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB042956727E97D7809DE57D44AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <VI1PR83MB042956727E97D7809DE57D44AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <52b2def9d4b4aad47968cbbee7760fa8c82d4afa.camel@joachim-breitner.de>

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From rae at richarde.dev  Mon Oct 19 14:07:01 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Mon, 19 Oct 2020 14:07:01 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
Message-ID: <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>

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 <trupill at gmail.com> 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 (<ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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 <ghc-steering-committee-
> |  bounces at haskell.org <mailto:bounces at haskell.org>> On Behalf Of Joachim Breitner
> |  Sent: 18 October 2020 22:01
> |  To: ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d809644bd069
> |  9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681
> |  5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> |  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
> |  pFwJB8wvBxWULqIqFes%3D&amp;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 at joachim-breitner.de <mailto:mail at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d8096
> |  44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
> |  86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> |  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3csJZH2Ux30FM4OIpLb
> |  QubZ0lVmz93H8j3Ko1X%2FOTaM%3D&amp;reserved=0
> |  
> |  
> |  _______________________________________________
> |  ghc-steering-committee mailing list
> |  ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com <http://40microsoft.com/>%7Cbdddd9d809644bd0
> |  699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516
> |  815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> |  CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SpEo1OwwBHDb7uIlkgBrnKbL
> |  QKwKyWug5dv9Y5coJcQ%3D&amp;reserved=0
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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

From trupill at gmail.com  Mon Oct 19 14:16:53 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 19 Oct 2020 16:16:53 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
Message-ID: <CAHnFXOvxSZK+n8vdySAOSftfD8fMqDnmJmHF5=MEK2Cs0CTUuQ@mail.gmail.com>

We have 50 answers in just 30 minutes :O

El lun., 19 oct. 2020 a las 16:07, Richard Eisenberg (<rae at richarde.dev>)
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 <trupill at gmail.com>
> 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 (<ghc-steering-committee at 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 <ghc-steering-committee-
>> |  bounces at haskell.org> On Behalf Of Joachim Breitner
>> |  Sent: 18 October 2020 22:01
>> |  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7Cbdddd9d809644bd069
>> |  9f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63738651681
>> |  5002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
>> |  BTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=gw0IAOeYqR7PwypWK4KuGs%2Bg
>> |  pFwJB8wvBxWULqIqFes%3D&amp;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 at joachim-breitner.de
>> |
>> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.jo
>> |  achim-
>> |  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7Cbdddd9d8096
>> |  44bd0699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373
>> |  86516815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
>> |  MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3csJZH2Ux30FM4OIpLb
>> |  QubZ0lVmz93H8j3Ko1X%2FOTaM%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>> |  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com
>> %7Cbdddd9d809644bd0
>> |  699f08d873a8f25d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637386516
>> |  815002112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>> |  CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SpEo1OwwBHDb7uIlkgBrnKbL
>> |  QKwKyWug5dv9Y5coJcQ%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
>>
> _______________________________________________
> 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/20201019/ff51718b/attachment-0001.html>

From mail at joachim-breitner.de  Mon Oct 19 15:05:16 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 19 Oct 2020 17:05:16 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
Message-ID: <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From trupill at gmail.com  Mon Oct 19 19:24:08 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Mon, 19 Oct 2020 21:24:08 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
 <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>
Message-ID: <CAHnFXOsE3AyV55sk9c2hiJX_-07Nh1ubvXBJNipi-YJjjSOnMg@mail.gmail.com>

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 at 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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201019/226d310e/attachment.html>

From simonpj at microsoft.com  Tue Oct 20 07:23:31 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 20 Oct 2020 07:23:31 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <CAHnFXOsE3AyV55sk9c2hiJX_-07Nh1ubvXBJNipi-YJjjSOnMg@mail.gmail.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
 <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>
 <CAHnFXOsE3AyV55sk9c2hiJX_-07Nh1ubvXBJNipi-YJjjSOnMg@mail.gmail.com>
Message-ID: <VI1PR83MB0429612CAAD8823A1111DB8CAD1F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 19 October 2020 20:24
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
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 (<mail at joachim-breitner.de<mailto:mail at 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 at joachim-breitner.de<mailto:mail at 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 at haskell.org<mailto: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=04%7C01%7Csimonpj%40microsoft.com%7Ccc54e3a12f5843a64e5908d874649b76%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637387322741398332%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yTvhE7jxAPBkmNSfXdF6KXAD8%2BQiRMDp%2B7ip9WTCTNU%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201020/c820258d/attachment-0001.html>

From arnaud.spiwack at tweag.io  Wed Oct 21 06:39:29 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 21 Oct 2020 08:39:29 +0200
Subject: [ghc-steering-committee] #283: Local modules,
	recommendation: accept
In-Reply-To: <CAHnFXOvzoxfRyViB3TcvwrQTOR1WQPwM=K=i3PQdDgAXshMwpQ@mail.gmail.com>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
 <46858f58fc6a1f95b13b5cc6bf5a5756edf31aec.camel@joachim-breitner.de>
 <CAH6fHQn=ZTg02vOohJV3nXgf845_UjV17ifNOXQC=DzSpt8VkA@mail.gmail.com>
 <CAHnFXOvzoxfRyViB3TcvwrQTOR1WQPwM=K=i3PQdDgAXshMwpQ@mail.gmail.com>
Message-ID: <CAH6fHQkVni0nZPsuAdx3JbrtH2moA+THmL0XMk2baZ_phCT2rw@mail.gmail.com>

Simon (Marlow):

Do I understand correctly that what you are objecting to is the following
syntax in the proposal

   module M where
   import module M where

And would rather have

  qualified module M where
  module M where

To mimic the import declaration behaviour?

On Sat, Oct 17, 2020 at 9:33 PM Alejandro Serrano Mena <trupill at gmail.com>
wrote:

> I like the proposal as it stands.
>
> El jue., 15 oct. 2020 a las 20:09, Spiwack, Arnaud (<
> arnaud.spiwack at tweag.io>) escribió:
>
>>
>> In
>>> particular excited about the ability to locally open a module
>>> (something that I began to like when writing Ocaml).
>>>
>>
>> It is also one of my favourite features in Ocaml. It's a fairly recent
>> addition to Ocaml (10ish years ago, I would say?), and I believe it's fair
>> to say that it had a profound impact on coding style throughout the
>> community. For the better in my opinion.
>> _______________________________________________
>> 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/20201021/10373012/attachment.html>

From mail at joachim-breitner.de  Thu Oct 22 07:31:40 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Oct 2020 09:31:40 +0200
Subject: [ghc-steering-committee]  Please review #369: Add sumToTag# primop,
 Shepherd: Eric
Message-ID: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>

Dear Committee,

this is your secretary speaking:

Add sumToTag# primop
has been proposed by David Feuer
https://github.com/ghc-proposals/ghc-proposals/pull/369
https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md

I’ll propose Eric Seidel as the shepherd.

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

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



From mail at joachim-breitner.de  Thu Oct 22 14:07:36 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Thu, 22 Oct 2020 16:07:36 +0200
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <VI1PR83MB0429612CAAD8823A1111DB8CAD1F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
 <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>
 <CAHnFXOsE3AyV55sk9c2hiJX_-07Nh1ubvXBJNipi-YJjjSOnMg@mail.gmail.com>
 <VI1PR83MB0429612CAAD8823A1111DB8CAD1F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <21df81341aad82f27ecdd8ff190d6880bfe8e844.camel@joachim-breitner.de>

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From marlowsd at gmail.com  Fri Oct 23 07:36:51 2020
From: marlowsd at gmail.com (Simon Marlow)
Date: Fri, 23 Oct 2020 08:36:51 +0100
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <21df81341aad82f27ecdd8ff190d6880bfe8e844.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <010f0175412f51f8-dd139ab9-50a0-4e43-b9bd-d74c1d66284c-000000@us-east-2.amazonses.com>
 <3bcdb85172874667724b866c76a2b4656eb421e3.camel@joachim-breitner.de>
 <CAHnFXOsE3AyV55sk9c2hiJX_-07Nh1ubvXBJNipi-YJjjSOnMg@mail.gmail.com>
 <VI1PR83MB0429612CAAD8823A1111DB8CAD1F0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <21df81341aad82f27ecdd8ff190d6880bfe8e844.camel@joachim-breitner.de>
Message-ID: <CANsrgPJwvCqECaPikKhRmq65ECrWd4sep0PvVW8p_Z7H-O-Wng@mail.gmail.com>

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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201023/54740828/attachment.html>

From mail at joachim-breitner.de  Mon Oct 26 15:37:12 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 26 Oct 2020 16:37:12 +0100
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <3873f800c61946aa579b656e0910ad1e0c4073d3.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <3873f800c61946aa579b656e0910ad1e0c4073d3.camel@joachim-breitner.de>
Message-ID: <319192c501327e0370f13a614742fc9605cd473e.camel@joachim-breitner.de>

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_excite_you/

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Mon Oct 26 16:32:45 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 26 Oct 2020 17:32:45 +0100
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <319192c501327e0370f13a614742fc9605cd473e.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <3873f800c61946aa579b656e0910ad1e0c4073d3.camel@joachim-breitner.de>
 <319192c501327e0370f13a614742fc9605cd473e.camel@joachim-breitner.de>
Message-ID: <8bddf302bf7c92501c3ad7a1569e57c8bd757610.camel@joachim-breitner.de>

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_excite_you/

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 at joachim-breitner.de
  http://www.joachim-breitner.de/



From simonpj at microsoft.com  Tue Oct 27 10:29:19 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Oct 2020 10:29:19 +0000
Subject: [ghc-steering-committee] GHC 2020
In-Reply-To: <319192c501327e0370f13a614742fc9605cd473e.camel@joachim-breitner.de>
References: <VI1PR83MB042979CA35B7DF0F9341FB7CAD290@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <9F56796E-29EE-4BBD-949F-4A86ACF57E6C@seidel.io>
 <CAHnFXOt2O3rMwetZ5m-+dDd08-=zY+v2ZSYA5t7p8jFr8mA9dA@mail.gmail.com>
 <CAH6fHQ=rL-YrqTehDS0QZiz5Aqi3=Y_6U34vV74izgUCsQHY_g@mail.gmail.com>
 <CANsrgPJZcS7vFuXKB-zTU2Q8j+z2pzzMx7msY+4D-QR9--nBaA@mail.gmail.com>
 <CAHnFXOt-fOcKbNpdbMz+mFCUFcRswaGOSZLc8fDTWP9gQ_k8Kw@mail.gmail.com>
 <010f0174da44e945-f65d0d5d-3f4c-47eb-a565-bd309bcf9876-000000@us-east-2.amazonses.com>
 <CAHnFXOusGTTekJrfU9iCOM6PnKWQ+Y8FQd34fnvmMQFboFn6wA@mail.gmail.com>
 <VI1PR83MB042951F40A0BA308FB964CB8AD320@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nuqSpaYo_Q6a=c6u9ivdsq5C9iUnoHxhm+rZGKDXKDSj4g@mail.gmail.com>
 <CAHnFXOtB_HX4omRZm2CvxFX1uHtrtGLVLVC0PT-04FaOwSe+VQ@mail.gmail.com>
 <VI1PR83MB0429CFC3EC04AE9738E34EDCAD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOu9CUyVoegfCK=LqE2i2Xt+5qb3VnaW8nMKTVfnaWik_A@mail.gmail.com>
 <VI1PR83MB04292E0F1DBCF37425ED6907AD300@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAGK9nupksaq9ExjyTBUfbYrvUk4YYaZu4VyjcdXza5GOBy-KJQ@mail.gmail.com>
 <CAHnFXOuWP5TBja3=mf9K+0fxEd9E7iTabhOwjWCo4mO=87Y=DA@mail.gmail.com>
 <010f0174e9f2ad23-9b0d1997-ba90-42bf-9031-bca5e3801bbb-000000@us-east-2.amazonses.com>
 <CAHnFXOuxJMKXTt2LskGy8U5+gVbEU503aBAtNb7zRECEWfBGxw@mail.gmail.com>
 <CANsrgP+kt0F_K3FRORkWtJeW3G2PCoL7oxK5Dzm1pYHkCU825A@mail.gmail.com>
 <65b5c19bc6737483a7a6a9e880dd617b546d8484.camel@joachim-breitner.de>
 <CAHnFXOtZ8Pks3V9E-rJNvoONbwtMEaC8LowdwyhXUotx7o3q4A@mail.gmail.com>
 <b8ad547f073aec58f92206208347d712e008c6de.camel@joachim-breitner.de>
 <VI1PR83MB0429E8411F8FC996F499E2C3AD1E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
 <CAHnFXOvvx0BdsWmTzrW370bKYBQhWaXjJ14wZEiBUeLR9wjUgQ@mail.gmail.com>
 <3873f800c61946aa579b656e0910ad1e0c4073d3.camel@joachim-breitner.de>
 <319192c501327e0370f13a614742fc9605cd473e.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB042987F108062085C222EE40AD160@VI1PR83MB0429.EURPRD83.prod.outlook.com>

|  If no discussion arises, I’ll formally submit this soon. 

Sounds fine to me.  Thank Joachim.

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 26 October 2020 15:37
|  To: ghc-steering-committee at 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47b
|  af714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C
|  637393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
|  iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VWt1s7T8wi3mB
|  mGLrOASPgOcQUhu003uPI9Juet0aTc%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Cca
|  e6b47baf714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SvTGu1w
|  l%2BC8OiwXEq0YrSZM8hjTxCq79obE%2FN73mBSo%3D&amp;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 at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47baf
|  714d1a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7393234538994698%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BPpXK%2F0rHIbhj
|  t0xta2Ptjoc9t6fGWHhoopy0qQxqPU%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7Ccae6b47baf714d1
|  a496808d879c50d45%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373932
|  34539004692%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=VOBV5UDa1qqQN%2BtZgj
|  ZfnsfO%2FLX42ij1AW09DpCqs0o%3D&amp;reserved=0

From mail at joachim-breitner.de  Tue Oct 27 17:52:59 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Oct 2020 18:52:59 +0100
Subject: [ghc-steering-committee] Proposal #302: `\of`
In-Reply-To: <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <010f017455fde7c2-d0af078b-24b8-4c12-95fc-7c653a7251f8-000000@us-east-2.amazonses.com>
 <CANsrgPLaR8xDM8oeK_b3Y31=nnAR7XDXyvaERoQqsys2vy7khA@mail.gmail.com>
 <VI1PR83MB0429E45795DEF8313400D7C8AD3E0@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <feeee53d6e72ba1e66b83370bf5832edcf48469c.camel@joachim-breitner.de>

Hi,

Am Donnerstag, den 17.09.2020, 15:22 +0000 schrieb Simon Peyton Jones
via ghc-steering-committee:
> If it was re-cast as \mcase, which is just like \case but allows n-ary functions, I’d find it quite acceptable.  The two then become extremely close, so there’s a very low cognitive load.  
>  
> GHC’s internals already allow this, and it seems surprisingly non-orthogonal that the source language does not.
>  
> We could kill off MultiWayIf.
>  
> But I don’t feel strongly.  If a consensus does not emerge, maybe we should just vote.


Cale, as the shepherd, could you lead us here to a resolution? I see
many voices in favor of rejection, but not really consensus yet.

Cheers,
Joachim

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



From mail at joachim-breitner.de  Tue Oct 27 17:59:54 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Oct 2020 18:59:54 +0100
Subject: [ghc-steering-committee] #283: Local modules,
 recommendation: accept
In-Reply-To: <CANsrgPJ6WvnjcSjhfiZPzDX1UMmBNWku5X2V6APyya4OE1ADJQ@mail.gmail.com>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
 <CANsrgPJ6WvnjcSjhfiZPzDX1UMmBNWku5X2V6APyya4OE1ADJQ@mail.gmail.com>
Message-ID: <81c03773aba5bebbb0545ca0bcdd71f4f433bfe0.camel@joachim-breitner.de>

Hi,

it seems that there are refinements possible. So even if most comments
were supportive so far, shall we send it back to “needs revision” and
discuss on the Github thread?

Cheers,
Joachim


Am Freitag, den 16.10.2020, 10:03 +0100 schrieb Simon Marlow:
> I like the proposal. Particularly I like that "it's just namespacing", you can explain everything in terms of what entities are in scope with what names.
> 
> But one thing jars with me:
> 
> * In existing import statements, names are made available both qualified and unqualified unless you say "qualified", in which case only the qualified names are brought into scope.
> * In this proposal, the "qualified" convention is extended to data/class/.. declarations, and to module exports. That's all fine.
> * However, local modules use a different convention: you get only the qualified names by default unless you add the "import" keyword to bring into scope the unqualified names. This applies both to a local module declaration at the top level, and to the import of a local module in an import list.
> 
> Why the inconsistency here? Can't we use the "qualified" convention everywhere? I think I would rather prefer to write
> 
>    qualified module M (x,y) where ...
> 
> to make it clear that you have to refer to M.x qualified. That's a lot more consistent with import statements.
> 
> Perhaps the concern is that if you just "import M" and M contains local modules, we want those modules to be imported qualified by default. But we could just state that to be the case, so that you have to explicitly "import M (module N)" to bring N's entities into scope unqualified.
> 
> Cheers
> Simon
> 
> 
> On Wed, 14 Oct 2020 at 15:08, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
> > Dear all,
> > 
> > I would like to bring our own Richard Eisenberg’s proposal, #283: Local modules, to your attention.
> > https://github.com/ghc-proposals/ghc-proposals/pull/283
> > 
> > The proposal is an attempt at solving the long debated issue that we can’t export qualified names out of a module (e.g. we may have to repeat import qualified Data.Map as Map and import qualified Data.Set as Set in every module in a project, rather than simply calling import MyPrelude which would take care of both and more), to improve scope management, and sharing names between types in the same files, while making namespaces more convenient to use in the process.
> > 
> > It’s a pretty ambitious proposal, with quite a few interlocking pieces. Yet, in my opinion, they fit pretty well together. And I’m, as a potential consumer, very enthusiastic about it.
> > 
> > Some highlight (though do read the whole thing):
> > 
> > We can define modules inside of other modules, with the syntax module Foo (some, optional, exports) where …
> > Like in the rest of Haskell, modules are no more than namespaces. Therefore you can open two module Foo, it will just merge the names in them
> > Values in local modules can be referred to, qualified, in the encompassing module
> > Local modules can be exported, importing them will import the name as qualified
> > A new import module Foo statement can be used in let and where clauses, it brings everything of the form Foo.x into scope unqualified for the scope of the let or where
> > Additionally, there is a small point that is not integral to the rest of the proposal, where defining, say, a type
> > 
> > data T
> >   = A
> >   | B
> > Would create a local module named T, such that the constructors could be referred to as T.A and T.B. I mention it separately, because it causes the only (small) backward incompatibility (that is Haskell 2010 programs which stop compiling when you turn on -XLocalModules).
> > 
> > I’m rather in favour of keeping it in, but it’s worth mentioning.
> > 
> > I pretty much want all of these features in my daily programming, so, as I said above, I’m very enthusiastic for all of this. And I’m pretty happy with the realisation. Hence my recommending acceptance.
> > 
> > /Arnaud
> > 
> > _______________________________________________
> > 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
-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/



From mail at joachim-breitner.de  Tue Oct 27 18:01:49 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Oct 2020 19:01:49 +0100
Subject: [ghc-steering-committee]  Status
Message-ID: <8e990745386e69a1c1ab858b42336310263d98cd.camel@joachim-breitner.de>

Dear Committee,

another “regular” status update. So what has happened in the last two months?

 * Lots of discussion about GHC2020. Enough to make it rather GHC2021.
 
 * Richard refines the bylaws in #360. Maybe everybody has a second
   look now and then we can merge this?

 * we were asked to review these proposals:
   #356: Linear Types arrow, shepherd: Richard
   #351: NoIncomplete, shepherd: Iavor
   #364: Unify Nat and Natural, shepherd: Alejandro
   #283: Local modules, Shepherd: Arnaud
   #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
   #369: Add sumToTag# primop, Shepherd: Eric

 * we have a recommendation from the shepherd about:
   #302: \of (rec: reject)
   #356: Linear Types arrow (rec: vote)
   #364: Unify Nat and Natural (rec: accept)
   #281: Visible 'forall' in types of terms (rec: accept)
   #283: Local modules (rec: accept)

 * we have sent the following proposals back to revision
   #281: Visible 'forall' in types of terms

 * we decided about the following proposals
   #356: Linear Types arrow (accept)
   #364: Unify Nat and Natural (accept)


We currently have to act on the following 5 proposals, up by 3.

## Waiting for committee decision

#313: Delimited continuation primops, Shepherd: Simon Marlow


#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow


## Waiting for Shepherd action

#333: Defer Parse Errors, Shepherd: Tom
      Tom, is this ready for Committee consideration?

#302: Layout and Guards in Lambda Expressions, Shepherd: Cale
      Cale, it is high time to jump into action here!


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



From mail at joachim-breitner.de  Tue Oct 27 18:04:35 2020
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Tue, 27 Oct 2020 19:04:35 +0100
Subject: [ghc-steering-committee]  Status (complete)
Message-ID: <f133b801acece4d0c7126817bd606eb32f7e4c35.camel@joachim-breitner.de>

[previous message was sent prematurely, sorry]

Dear Committee,

another “regular” status update. So what has happened in the last two months?

 * Lots of discussion about GHC2020. Enough to make it rather GHC2021.
 
 * Richard refines the bylaws in #360. Maybe everybody has a second
   look now and then we can merge this?

 * we were asked to review these proposals:
   #356: Linear Types arrow, shepherd: Richard
   #351: NoIncomplete, shepherd: Iavor
   #364: Unify Nat and Natural, shepherd: Alejandro
   #283: Local modules, Shepherd: Arnaud
   #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
   #369: Add sumToTag# primop, Shepherd: Eric

 * we have a recommendation from the shepherd about:
   #302: \of (rec: reject)
   #356: Linear Types arrow (rec: vote)
   #364: Unify Nat and Natural (rec: accept)
   #281: Visible 'forall' in types of terms (rec: accept)
   #283: Local modules (rec: accept)

 * we have sent the following proposals back to revision
   #281: Visible 'forall' in types of terms

 * we decided about the following proposals
   #356: Linear Types arrow (accept)
   #364: Unify Nat and Natural (accept)


We currently have to act on the following 5 proposals, up by 3.

## Waiting for committee decision

#283: Local modules, Shepherd: Arnaud
      Mostly positive, may need more revision though

#302: \of, Shepherd: Cale
      Mostly negative, but still discussion going on.

## Waiting for Shepherd action


#313: Delimited continuation primops, Shepherd: Simon Marlow
      This one is aging. Simon, are you on this?

#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
      Still rather new.

#369: Add sumToTag# primop, Shepherd: Eric
      Still rather new.


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



From rae at richarde.dev  Tue Oct 27 18:24:34 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Tue, 27 Oct 2020 18:24:34 +0000
Subject: [ghc-steering-committee] #283: Local modules,
 recommendation: accept
In-Reply-To: <81c03773aba5bebbb0545ca0bcdd71f4f433bfe0.camel@joachim-breitner.de>
References: <CAH6fHQmCv5jEcZZgcMHoHmt4Qym28feYANdYcD4AeHrktj1v8A@mail.gmail.com>
 <CANsrgPJ6WvnjcSjhfiZPzDX1UMmBNWku5X2V6APyya4OE1ADJQ@mail.gmail.com>
 <81c03773aba5bebbb0545ca0bcdd71f4f433bfe0.camel@joachim-breitner.de>
Message-ID: <010f01756b4dfc67-cac6c120-88a3-4c9e-af4a-9e49edf85194-000000@us-east-2.amazonses.com>

Yes. I've taken the liberty to mark this as Needs revision. I will revise to improve the clarity of the proposal. I do not expect any technical details to change.

Richard

> On Oct 27, 2020, at 1:59 PM, Joachim Breitner <mail at joachim-breitner.de> wrote:
> 
> Hi,
> 
> it seems that there are refinements possible. So even if most comments
> were supportive so far, shall we send it back to “needs revision” and
> discuss on the Github thread?
> 
> Cheers,
> Joachim
> 
> 
> Am Freitag, den 16.10.2020, 10:03 +0100 schrieb Simon Marlow:
>> I like the proposal. Particularly I like that "it's just namespacing", you can explain everything in terms of what entities are in scope with what names.
>> 
>> But one thing jars with me:
>> 
>> * In existing import statements, names are made available both qualified and unqualified unless you say "qualified", in which case only the qualified names are brought into scope.
>> * In this proposal, the "qualified" convention is extended to data/class/.. declarations, and to module exports. That's all fine.
>> * However, local modules use a different convention: you get only the qualified names by default unless you add the "import" keyword to bring into scope the unqualified names. This applies both to a local module declaration at the top level, and to the import of a local module in an import list.
>> 
>> Why the inconsistency here? Can't we use the "qualified" convention everywhere? I think I would rather prefer to write
>> 
>>   qualified module M (x,y) where ...
>> 
>> to make it clear that you have to refer to M.x qualified. That's a lot more consistent with import statements.
>> 
>> Perhaps the concern is that if you just "import M" and M contains local modules, we want those modules to be imported qualified by default. But we could just state that to be the case, so that you have to explicitly "import M (module N)" to bring N's entities into scope unqualified.
>> 
>> Cheers
>> Simon
>> 
>> 
>> On Wed, 14 Oct 2020 at 15:08, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:
>>> Dear all,
>>> 
>>> I would like to bring our own Richard Eisenberg’s proposal, #283: Local modules, to your attention.
>>> https://github.com/ghc-proposals/ghc-proposals/pull/283
>>> 
>>> The proposal is an attempt at solving the long debated issue that we can’t export qualified names out of a module (e.g. we may have to repeat import qualified Data.Map as Map and import qualified Data.Set as Set in every module in a project, rather than simply calling import MyPrelude which would take care of both and more), to improve scope management, and sharing names between types in the same files, while making namespaces more convenient to use in the process.
>>> 
>>> It’s a pretty ambitious proposal, with quite a few interlocking pieces. Yet, in my opinion, they fit pretty well together. And I’m, as a potential consumer, very enthusiastic about it.
>>> 
>>> Some highlight (though do read the whole thing):
>>> 
>>> We can define modules inside of other modules, with the syntax module Foo (some, optional, exports) where …
>>> Like in the rest of Haskell, modules are no more than namespaces. Therefore you can open two module Foo, it will just merge the names in them
>>> Values in local modules can be referred to, qualified, in the encompassing module
>>> Local modules can be exported, importing them will import the name as qualified
>>> A new import module Foo statement can be used in let and where clauses, it brings everything of the form Foo.x into scope unqualified for the scope of the let or where
>>> Additionally, there is a small point that is not integral to the rest of the proposal, where defining, say, a type
>>> 
>>> data T
>>>  = A
>>>  | B
>>> Would create a local module named T, such that the constructors could be referred to as T.A and T.B. I mention it separately, because it causes the only (small) backward incompatibility (that is Haskell 2010 programs which stop compiling when you turn on -XLocalModules).
>>> 
>>> I’m rather in favour of keeping it in, but it’s worth mentioning.
>>> 
>>> I pretty much want all of these features in my daily programming, so, as I said above, I’m very enthusiastic for all of this. And I’m pretty happy with the realisation. Hence my recommending acceptance.
>>> 
>>> /Arnaud
>>> 
>>> _______________________________________________
>>> 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
> -- 
> Joachim Breitner
>  mail at joachim-breitner.de
>  http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee


From iavor.diatchki at gmail.com  Tue Oct 27 18:26:09 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 27 Oct 2020 11:26:09 -0700
Subject: [ghc-steering-committee] Status
In-Reply-To: <8e990745386e69a1c1ab858b42336310263d98cd.camel@joachim-breitner.de>
References: <8e990745386e69a1c1ab858b42336310263d98cd.camel@joachim-breitner.de>
Message-ID: <CAGK9nupH7MZYtxO427Sc1cPVpe3WS-taHpcd8qm_TmR4QWGQFw@mail.gmail.com>

On #281 I initially recommended acceptance, but after the discussion I
realized that I haven't fully understood all the implications of the
proposal, and some tricky issues came up, so we changed the status to
"needs revision".   After a short period of time, the author asked me to
resubmit the proposal again, but there appears to be a bunch of discussion
still happening, so I am waiting for things to calm down again, before I
read it again, and see what's changed.

I have some deadlines coming up, so I won't be able to deal with committee
stuff until about mid next week---apologies for that, hopefully nothing is
particularly urgent.

-Iavor



On Tue, Oct 27, 2020 at 11:02 AM Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Dear Committee,
>
> another “regular” status update. So what has happened in the last two
> months?
>
>  * Lots of discussion about GHC2020. Enough to make it rather GHC2021.
>
>  * Richard refines the bylaws in #360. Maybe everybody has a second
>    look now and then we can merge this?
>
>  * we were asked to review these proposals:
>    #356: Linear Types arrow, shepherd: Richard
>    #351: NoIncomplete, shepherd: Iavor
>    #364: Unify Nat and Natural, shepherd: Alejandro
>    #283: Local modules, Shepherd: Arnaud
>    #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>    #369: Add sumToTag# primop, Shepherd: Eric
>
>  * we have a recommendation from the shepherd about:
>    #302: \of (rec: reject)
>    #356: Linear Types arrow (rec: vote)
>    #364: Unify Nat and Natural (rec: accept)
>    #281: Visible 'forall' in types of terms (rec: accept)
>    #283: Local modules (rec: accept)
>
>  * we have sent the following proposals back to revision
>    #281: Visible 'forall' in types of terms
>
>  * we decided about the following proposals
>    #356: Linear Types arrow (accept)
>    #364: Unify Nat and Natural (accept)
>
>
> We currently have to act on the following 5 proposals, up by 3.
>
> ## Waiting for committee decision
>
> #313: Delimited continuation primops, Shepherd: Simon Marlow
>
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>
>
> ## Waiting for Shepherd action
>
> #333: Defer Parse Errors, Shepherd: Tom
>       Tom, is this ready for Committee consideration?
>
> #302: Layout and Guards in Lambda Expressions, Shepherd: Cale
>       Cale, it is high time to jump into action here!
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201027/861f1a84/attachment.html>

From simonpj at microsoft.com  Tue Oct 27 20:27:18 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Oct 2020 20:27:18 +0000
Subject: [ghc-steering-committee] Status
In-Reply-To: <CAGK9nupH7MZYtxO427Sc1cPVpe3WS-taHpcd8qm_TmR4QWGQFw@mail.gmail.com>
References: <8e990745386e69a1c1ab858b42336310263d98cd.camel@joachim-breitner.de>
 <CAGK9nupH7MZYtxO427Sc1cPVpe3WS-taHpcd8qm_TmR4QWGQFw@mail.gmail.com>
Message-ID: <VI1PR83MB0429CBA85C89C5B610B7C3F4AD160@VI1PR83MB0429.EURPRD83.prod.outlook.com>

After a short period of time, the author asked me to resubmit the proposal again, but there appears to be a bunch of discussion still happening, so I am waiting for things to calm down again, before I read it again, and see what's changed.
You might want to let the author know.   Committee discussion is a bit stalled until you give a recommendation.

Alternatively you could be asking us to express an opinion about the proposal in its current state?

I’m just conscious that no proposal should sit in the committee’s bailiwick for long.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Iavor Diatchki
Sent: 27 October 2020 18:26
To: Joachim Breitner <mail at joachim-breitner.de>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Status

On #281 I initially recommended acceptance, but after the discussion I realized that I haven't fully understood all the implications of the proposal, and some tricky issues came up, so we changed the status to "needs revision".   After a short period of time, the author asked me to resubmit the proposal again, but there appears to be a bunch of discussion still happening, so I am waiting for things to calm down again, before I read it again, and see what's changed.

I have some deadlines coming up, so I won't be able to deal with committee stuff until about mid next week---apologies for that, hopefully nothing is particularly urgent.

-Iavor



On Tue, Oct 27, 2020 at 11:02 AM Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,

another “regular” status update. So what has happened in the last two months?

 * Lots of discussion about GHC2020. Enough to make it rather GHC2021.

 * Richard refines the bylaws in #360. Maybe everybody has a second
   look now and then we can merge this?

 * we were asked to review these proposals:
   #356: Linear Types arrow, shepherd: Richard
   #351: NoIncomplete, shepherd: Iavor
   #364: Unify Nat and Natural, shepherd: Alejandro
   #283: Local modules, Shepherd: Arnaud
   #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
   #369: Add sumToTag# primop, Shepherd: Eric

 * we have a recommendation from the shepherd about:
   #302: \of (rec: reject)
   #356: Linear Types arrow (rec: vote)
   #364: Unify Nat and Natural (rec: accept)
   #281: Visible 'forall' in types of terms (rec: accept)
   #283: Local modules (rec: accept)

 * we have sent the following proposals back to revision
   #281: Visible 'forall' in types of terms

 * we decided about the following proposals
   #356: Linear Types arrow (accept)
   #364: Unify Nat and Natural (accept)


We currently have to act on the following 5 proposals, up by 3.

## Waiting for committee decision

#313: Delimited continuation primops, Shepherd: Simon Marlow


#367: Clarify primops using unboxed sums, Shepherd: Simon Marlow


## Waiting for Shepherd action

#333: Defer Parse Errors, Shepherd: Tom
      Tom, is this ready for Committee consideration?

#302: Layout and Guards in Lambda Expressions, Shepherd: Cale
      Cale, it is high time to jump into action here!


Cheers,
Joachim
--
Joachim Breitner
  mail at joachim-breitner.de<mailto:mail at 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%7Cb09bb398b6994336807d08d87aa5d390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394199923776422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wRy1%2FGf7IgAYhHOMuod7JofjCZbNeFwiqsK34Cny5fU%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://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%7Cb09bb398b6994336807d08d87aa5d390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394199923776422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MfQeAmjPtAiv92jI8hK%2BbiocmWnt%2FTYILVT1TMnKF9I%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201027/3c4073d4/attachment-0001.html>

From simonpj at microsoft.com  Tue Oct 27 20:41:11 2020
From: simonpj at microsoft.com (Simon Peyton Jones)
Date: Tue, 27 Oct 2020 20:41:11 +0000
Subject: [ghc-steering-committee] Status (complete)
In-Reply-To: <f133b801acece4d0c7126817bd606eb32f7e4c35.camel@joachim-breitner.de>
References: <f133b801acece4d0c7126817bd606eb32f7e4c35.camel@joachim-breitner.de>
Message-ID: <VI1PR83MB042952F462A05D59A4CCBA65AD160@VI1PR83MB0429.EURPRD83.prod.outlook.com>

I'm conscious that our process says that

* A shepherd will make a recommendation within 2 weeks
* Committee will make a decision with 4 weeks after that

We are all busy, but I think it's good for us to have this discipline, else things tend to drift and proposal authors become discouraged.

Or at least, if we don’t think that is possible, let's change our guidelines.

"Decision" might mean "invite the authors to revise and resubmit".  Then the clck stops and we start again when they resubmit.

I think we said we'd appoint a "nudger" to watch the timetable (weekly perhaps) give the shepherds a nudge.  If successive nudges don't work (e.g. perhaps a committee member has bee overtaken by an emergency) then s/he can alert the Secretary to appoint a new shepherd.

Is anyone willing to take up that role, for, say six months? It's not onerous.

Thanks

Simon

|  -----Original Message-----
|  From: ghc-steering-committee <ghc-steering-committee-
|  bounces at haskell.org> On Behalf Of Joachim Breitner
|  Sent: 27 October 2020 18:05
|  To: ghc-steering-committee at haskell.org
|  Subject: [ghc-steering-committee] Status (complete)
|  
|  [previous message was sent prematurely, sorry]
|  
|  Dear Committee,
|  
|  another “regular” status update. So what has happened in the last two
|  months?
|  
|   * Lots of discussion about GHC2020. Enough to make it rather GHC2021.
|  
|   * Richard refines the bylaws in #360. Maybe everybody has a second
|     look now and then we can merge this?
|  
|   * we were asked to review these proposals:
|     #356: Linear Types arrow, shepherd: Richard
|     #351: NoIncomplete, shepherd: Iavor
|     #364: Unify Nat and Natural, shepherd: Alejandro
|     #283: Local modules, Shepherd: Arnaud
|     #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
|     #369: Add sumToTag# primop, Shepherd: Eric
|  
|   * we have a recommendation from the shepherd about:
|     #302: \of (rec: reject)
|     #356: Linear Types arrow (rec: vote)
|     #364: Unify Nat and Natural (rec: accept)
|     #281: Visible 'forall' in types of terms (rec: accept)
|     #283: Local modules (rec: accept)
|  
|   * we have sent the following proposals back to revision
|     #281: Visible 'forall' in types of terms
|  
|   * we decided about the following proposals
|     #356: Linear Types arrow (accept)
|     #364: Unify Nat and Natural (accept)
|  
|  
|  We currently have to act on the following 5 proposals, up by 3.
|  
|  ## Waiting for committee decision
|  
|  #283: Local modules, Shepherd: Arnaud
|        Mostly positive, may need more revision though
|  
|  #302: \of, Shepherd: Cale
|        Mostly negative, but still discussion going on.
|  
|  ## Waiting for Shepherd action
|  
|  
|  #313: Delimited continuation primops, Shepherd: Simon Marlow
|        This one is aging. Simon, are you on this?
|  
|  #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
|        Still rather new.
|  
|  #369: Add sumToTag# primop, Shepherd: Eric
|        Still rather new.
|  
|  
|  Cheers,
|  Joachim
|  --
|  Joachim Breitner
|    mail at joachim-breitner.de
|  
|  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j
|  oachim-
|  breitner.de%2F&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C640674f5a0
|  ab47a8ed1908d87aa2e2b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7394187303081020%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=NYRot2SPgmxFzL1
|  BeZA%2BYKdpbkbvsOO3tFaHbzIpyV8%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%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
|  committee&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C640674f5a0ab47a
|  8ed1908d87aa2e2b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373941
|  87303091011%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Vu4ZmGs88iweSUTwNPH%
|  2FH1p%2FagrY5p8DPJVvHNUisGE%3D&amp;reserved=0

From iavor.diatchki at gmail.com  Tue Oct 27 20:52:40 2020
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Tue, 27 Oct 2020 13:52:40 -0700
Subject: [ghc-steering-committee] Status
In-Reply-To: <VI1PR83MB0429CBA85C89C5B610B7C3F4AD160@VI1PR83MB0429.EURPRD83.prod.outlook.com>
References: <8e990745386e69a1c1ab858b42336310263d98cd.camel@joachim-breitner.de>
 <CAGK9nupH7MZYtxO427Sc1cPVpe3WS-taHpcd8qm_TmR4QWGQFw@mail.gmail.com>
 <VI1PR83MB0429CBA85C89C5B610B7C3F4AD160@VI1PR83MB0429.EURPRD83.prod.outlook.com>
Message-ID: <CAGK9nurJSGr8vGS9Eep8poHzcxqso0j0GcBds+-QnHZOQ=aM8A@mail.gmail.com>

I did let them know on github.  Also the proposal was resubmitted to the
committee only 4 days ago, so we are within the stated limits.

Also, I'd encourage members of the committee interested in the proposal to
continue the discussion, and not feel blocked by me.

-Iavor

On Tue, Oct 27, 2020 at 1:27 PM Simon Peyton Jones <simonpj at microsoft.com>
wrote:

> After a short period of time, the author asked me to resubmit the proposal
> again, but there appears to be a bunch of discussion still happening, so I
> am waiting for things to calm down again, before I read it again, and see
> what's changed.
>
> You might want to let the author know.   Committee discussion is a bit
> stalled until you give a recommendation.
>
>
>
> Alternatively you could be asking us to express an opinion about the
> proposal in its current state?
>
>
>
> I’m just conscious that no proposal should sit in the committee’s
> bailiwick for long.
>
>
>
> Simon
>
>
>
> *From:* ghc-steering-committee <ghc-steering-committee-bounces at haskell.org>
> *On Behalf Of *Iavor Diatchki
> *Sent:* 27 October 2020 18:26
> *To:* Joachim Breitner <mail at joachim-breitner.de>
> *Cc:* ghc-steering-committee <ghc-steering-committee at haskell.org>
> *Subject:* Re: [ghc-steering-committee] Status
>
>
>
> On #281 I initially recommended acceptance, but after the discussion I
> realized that I haven't fully understood all the implications of the
> proposal, and some tricky issues came up, so we changed the status to
> "needs revision".   After a short period of time, the author asked me to
> resubmit the proposal again, but there appears to be a bunch of discussion
> still happening, so I am waiting for things to calm down again, before I
> read it again, and see what's changed.
>
>
>
> I have some deadlines coming up, so I won't be able to deal with committee
> stuff until about mid next week---apologies for that, hopefully nothing is
> particularly urgent.
>
>
>
> -Iavor
>
>
>
>
>
>
>
> On Tue, Oct 27, 2020 at 11:02 AM Joachim Breitner <
> mail at joachim-breitner.de> wrote:
>
> Dear Committee,
>
> another “regular” status update. So what has happened in the last two
> months?
>
>  * Lots of discussion about GHC2020. Enough to make it rather GHC2021.
>
>  * Richard refines the bylaws in #360. Maybe everybody has a second
>    look now and then we can merge this?
>
>  * we were asked to review these proposals:
>    #356: Linear Types arrow, shepherd: Richard
>    #351: NoIncomplete, shepherd: Iavor
>    #364: Unify Nat and Natural, shepherd: Alejandro
>    #283: Local modules, Shepherd: Arnaud
>    #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>    #369: Add sumToTag# primop, Shepherd: Eric
>
>  * we have a recommendation from the shepherd about:
>    #302: \of (rec: reject)
>    #356: Linear Types arrow (rec: vote)
>    #364: Unify Nat and Natural (rec: accept)
>    #281: Visible 'forall' in types of terms (rec: accept)
>    #283: Local modules (rec: accept)
>
>  * we have sent the following proposals back to revision
>    #281: Visible 'forall' in types of terms
>
>  * we decided about the following proposals
>    #356: Linear Types arrow (accept)
>    #364: Unify Nat and Natural (accept)
>
>
> We currently have to act on the following 5 proposals, up by 3.
>
> ## Waiting for committee decision
>
> #313: Delimited continuation primops, Shepherd: Simon Marlow
>
>
> #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow
>
>
> ## Waiting for Shepherd action
>
> #333: Defer Parse Errors, Shepherd: Tom
>       Tom, is this ready for Committee consideration?
>
> #302: Layout and Guards in Lambda Expressions, Shepherd: Cale
>       Cale, it is high time to jump into action here!
>
>
> Cheers,
> Joachim
> --
> Joachim Breitner
>   mail at 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%7Cb09bb398b6994336807d08d87aa5d390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394199923776422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=wRy1%2FGf7IgAYhHOMuod7JofjCZbNeFwiqsK34Cny5fU%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
> <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%7Cb09bb398b6994336807d08d87aa5d390%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637394199923776422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MfQeAmjPtAiv92jI8hK%2BbiocmWnt%2FTYILVT1TMnKF9I%3D&reserved=0>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201027/c1a00a70/attachment-0001.html>

From eric at seidel.io  Tue Oct 27 23:51:56 2020
From: eric at seidel.io (Eric Seidel)
Date: Tue, 27 Oct 2020 19:51:56 -0400
Subject: [ghc-steering-committee]
 =?utf-8?q?Please_review_=23369=3A_Add_su?=
 =?utf-8?q?mToTag=23_primop=2C_Shepherd=3A_Eric?=
In-Reply-To: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
Message-ID: <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>

Hi all,

I have recommended acceptance of this proposal. It's a simple addition that fills what appears to be a gap in our API around unboxed sums (we already provide `dataToTag#` for lifted types).

Please take a look.

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

Thanks!
Eric

On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> Add sumToTag# primop
> has been proposed by David Feuer
> https://github.com/ghc-proposals/ghc-proposals/pull/369
> https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
> 
> I’ll propose Eric Seidel as the shepherd.
> 
> Please guide us to a conclusion as outlined in 
> https://github.com/ghc-proposals/ghc-proposals#committee-process
> 
> Thanks,
> Joachim
> -- 
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>

From arnaud.spiwack at tweag.io  Wed Oct 28 15:12:18 2020
From: arnaud.spiwack at tweag.io (Spiwack, Arnaud)
Date: Wed, 28 Oct 2020 16:12:18 +0100
Subject: [ghc-steering-committee] Please review #369: Add sumToTag#
 primop, Shepherd: Eric
In-Reply-To: <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
Message-ID: <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>

The wording of the specification section is still a bit awkward, in my
opinion. Other than that, I'm fine with the proposal.

On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io> wrote:

> Hi all,
>
> I have recommended acceptance of this proposal. It's a simple addition
> that fills what appears to be a gap in our API around unboxed sums (we
> already provide `dataToTag#` for lifted types).
>
> Please take a look.
>
> https://github.com/ghc-proposals/ghc-proposals/pull/369
>
> Thanks!
> Eric
>
> On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> > Dear Committee,
> >
> > this is your secretary speaking:
> >
> > Add sumToTag# primop
> > has been proposed by David Feuer
> > https://github.com/ghc-proposals/ghc-proposals/pull/369
> >
> https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
> >
> > I’ll propose Eric Seidel as the shepherd.
> >
> > Please guide us to a conclusion as outlined in
> > https://github.com/ghc-proposals/ghc-proposals#committee-process
> >
> > Thanks,
> > Joachim
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
> >
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201028/4ea237fb/attachment.html>

From trupill at gmail.com  Wed Oct 28 21:08:52 2020
From: trupill at gmail.com (Alejandro Serrano Mena)
Date: Wed, 28 Oct 2020 22:08:52 +0100
Subject: [ghc-steering-committee] Please review #369: Add sumToTag#
 primop, Shepherd: Eric
In-Reply-To: <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
Message-ID: <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>

I am also fine with the proposal.

Alejandro

El mié., 28 oct. 2020 a las 16:13, Spiwack, Arnaud (<arnaud.spiwack at tweag.io>)
escribió:

> The wording of the specification section is still a bit awkward, in my
> opinion. Other than that, I'm fine with the proposal.
>
> On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io> wrote:
>
>> Hi all,
>>
>> I have recommended acceptance of this proposal. It's a simple addition
>> that fills what appears to be a gap in our API around unboxed sums (we
>> already provide `dataToTag#` for lifted types).
>>
>> Please take a look.
>>
>> https://github.com/ghc-proposals/ghc-proposals/pull/369
>>
>> Thanks!
>> Eric
>>
>> On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
>> > Dear Committee,
>> >
>> > this is your secretary speaking:
>> >
>> > Add sumToTag# primop
>> > has been proposed by David Feuer
>> > https://github.com/ghc-proposals/ghc-proposals/pull/369
>> >
>> https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md
>> >
>> > I’ll propose Eric Seidel as the shepherd.
>> >
>> > Please guide us to a conclusion as outlined in
>> > https://github.com/ghc-proposals/ghc-proposals#committee-process
>> >
>> > Thanks,
>> > Joachim
>> > --
>> > Joachim Breitner
>> >   mail at joachim-breitner.de
>> >   http://www.joachim-breitner.de/
>> >
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> >
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201028/00c9c605/attachment.html>

From rae at richarde.dev  Thu Oct 29 13:30:36 2020
From: rae at richarde.dev (Richard Eisenberg)
Date: Thu, 29 Oct 2020 13:30:36 +0000
Subject: [ghc-steering-committee] Please review #369: Add sumToTag#
 primop, Shepherd: Eric
In-Reply-To: <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
References: <aeb980341be95777caa9a689f32b3d186b9870fa.camel@joachim-breitner.de>
 <d48f3d1a-f802-42bf-87cd-f22d3e6a1116@www.fastmail.com>
 <CAH6fHQn_y5=y6irfv+mD+zVS8tcNrnWMe2Z7RvSZ53LQi45EhA@mail.gmail.com>
 <CAHnFXOv+k+M33=mR7d7XrteSfo2h00ek-Vu8aPurD2wjYsWaAA@mail.gmail.com>
Message-ID: <010f0175748d93a9-ce8da12a-83f0-48a1-8eab-201acc6a85cd-000000@us-east-2.amazonses.com>

Yes, I support this.

Richard

> On Oct 28, 2020, at 5:08 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> I am also fine with the proposal.
> 
> Alejandro
> 
> El mié., 28 oct. 2020 a las 16:13, Spiwack, Arnaud (<arnaud.spiwack at tweag.io <mailto:arnaud.spiwack at tweag.io>>) escribió:
> The wording of the specification section is still a bit awkward, in my opinion. Other than that, I'm fine with the proposal.
> 
> On Wed, Oct 28, 2020 at 12:52 AM Eric Seidel <eric at seidel.io <mailto:eric at seidel.io>> wrote:
> Hi all,
> 
> I have recommended acceptance of this proposal. It's a simple addition that fills what appears to be a gap in our API around unboxed sums (we already provide `dataToTag#` for lifted types).
> 
> Please take a look.
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/369 <https://github.com/ghc-proposals/ghc-proposals/pull/369>
> 
> Thanks!
> Eric
> 
> On Thu, Oct 22, 2020, at 03:31, Joachim Breitner wrote:
> > Dear Committee,
> > 
> > this is your secretary speaking:
> > 
> > Add sumToTag# primop
> > has been proposed by David Feuer
> > https://github.com/ghc-proposals/ghc-proposals/pull/369 <https://github.com/ghc-proposals/ghc-proposals/pull/369>
> > https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md <https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum-to-tag.md>
> > 
> > I’ll propose Eric Seidel as the shepherd.
> > 
> > Please guide us to a conclusion as outlined in 
> > https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process>
> > 
> > Thanks,
> > Joachim
> > -- 
> > Joachim Breitner
> >   mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>
> >   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> > 
> > 
> > _______________________________________________
> > ghc-steering-committee mailing list
> > ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> >
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/20201029/99590214/attachment.html>