[ghc-steering-committee] GHC 2020
Alejandro Serrano Mena
trupill at gmail.com
Sun Oct 4 19:30:58 UTC 2020
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&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&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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977251776&sdata=KQfPgn0781%2Fi5JrFyEBp87Tcc3G%2FGiysbqlTM42Xgrw%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=X4VmXP6B65Tp%2Byv77g47%2FJiSx%2FdrScj5n5xMyzJKiik%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977261761&sdata=BdY%2Fv6at9nrPOSB4RqbhsDmjKopgJqGlYBEY6XcQhOM%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=r3dK4INyOAgjOC3GmkBGVkTcko6auZjST5815b8Gq9c%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977271759&sdata=4YyoqgXgYhjSanhyuMXMjEQsTZm3ux00U6O3mFv274g%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%7Cc51c2a01fa8248b2f7f108d865e28c00%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371370977281758&sdata=rwo%2BaTMPD6sIQAYIcyWg1DU5Ut71bgKxYIdp3mP9Iuo%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%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>
More information about the ghc-steering-committee
mailing list