[ghc-steering-committee] GHC 2020

[Alejandro Serrano Mena]

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&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&sdata=ABgJCFijwzYszRybc0kReMPdR7oSLzC1nV1xJYSlxQ0%3D
>>>> |  &reserved=0
>>>> |  >>
>>>> |  >>
>>>> |  >> _______________________________________________
>>>> |  >> ghc-steering-committee mailing list
>>>> |  >> ghc-steering-committee at haskell.org
>>>> |  >>
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>>> |  haskell.org
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634578651&sdata=3ksDaGjTZCq%2BE2tBzPqrjoQ9LQ3ikh3RUNgZsaAe9B4%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=Q89KmMJ87VLBBWVdemnhkZSEPtLvt6K8mp5ZNFihrnQ%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>>> |  amp;reserved=0
>>>> |  >
>>>> |  > _______________________________________________
>>>> |  > ghc-steering-committee mailing list
>>>> |  > ghc-steering-committee at haskell.org
>>>> |  >
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>>> |  haskell.org
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634588643&sdata=smlu8yLG%2FwgNoYFMv%2F3QnyHhqDMSvOjZk5e%2FtxLznKc%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634598642&sdata=mhXHnOFn4tKiYZy6h5WkpnGm4Hk5KFiDZYnUAdk5oZo%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>>> |  amp;reserved=0
>>>> |
>>>> |  _______________________________________________
>>>> |  ghc-steering-committee mailing list
>>>> |  ghc-steering-committee at haskell.org
>>>> |
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.
>>>> |  haskell.org
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=vyTjG7qSxDYx1SiUjMLoIcbGlZA0IWD%2B7cbqKDW0Rhs%3D&reserved=0>
>>>> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
>>>> |  committee&data=02%7C01%7Csimonpj%40microsoft.com
>>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=02%7C01%7Csimonpj%40microsoft.com%7Cf5ac3d83a2294463146608d864875f01%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637369880634608636&sdata=MBlt7msCwwJRG6UAowr8NcARtLSO2rWiDdqF3lmSzjg%3D&reserved=0>
>>>> %7Cfa6e3a6bcdf04ed5
>>>> |
>>>> 611208d84f480f21%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346518
>>>> |
>>>> 199468575&sdata=H1hFiX8qnuf%2FlYeNXfEE5j5Aik3dlVvsujoHOt%2FHTnw%3D&
>>>> |  amp;reserved=0
>>>> _______________________________________________
>>>> ghc-steering-committee mailing list
>>>> ghc-steering-committee at haskell.org
>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%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>