I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. Richard

On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee wrote:

I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-5475225...

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 05 November 2019 16:44 | To: ghc-steering-committee | Subject: [ghc-steering-committee] #195 recommendation: accept | | Hello everyone, | | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a | newtype synonym `Code a`. The main change to the language is that the | special Template Haskell notation for typed splices will will work | with `Code a` rather than `Q (TExtp a)`. | | The benefit of having the newtype is that it makes it possible to | abstract over `Code`. For example, you can work with typed name | environments like `MapF Name Code`, where `MapF` is an "indexed" | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in | package `parameterized-utils` on hackage). | | Making typed TH work with `Code` directly avoids the need to | constantly switch between `Code` and `Q (TExp a)` and with the new | system users of typed TH are not likely to deal with the latter much | at all. | | For these reasons I recommend that we accept this proposal. Please | let me know if you think otherwise. | | -Iavor | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | ved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

when the details are eventually sorted out But when will that be? Our criteria say that the proposal should stand by itself before we finally accept it. If there are specifics that we think belong in the proposal, then our protocol is: * tell the authors that we are minded to accept, * invite them to fill in the missing stuff and resubmit * change status to “needs revision” I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. Simon From: Spiwack, Arnaud Sent: 06 November 2019 08:46 To: Richard Eisenberg Cc: Simon Peyton Jones ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept I understand that some details are lacking. But I don't think, whatever the details are, that they will affect my opinion of the proposal: they are over my knowledge of Template Haskell. This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out. On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg mailto:rae@richarde.dev> wrote: I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`. Richard

On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee mailto:ghc-steering-committee@haskell.org> wrote:

I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-5475225...https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195%23issuecomment-547522510&data=02%7C01%7Csimonpj%40microsoft.com%7C527240705f664101bba108d76295dabb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086268899169898&sdata=n8uk%2Fnppc%2FjrfkQ31O9YTiEwenBgj%2FxZb70oFr4oX5M%3D&reserved=0

Simon

| -----Original Message----- | From: ghc-steering-committee mailto:ghc-steering-committee-bounces@haskell.org> | On Behalf Of Iavor Diatchki | Sent: 05 November 2019 16:44 | To: ghc-steering-committee mailto:ghc-steering-committee@haskell.org> | Subject: [ghc-steering-committee] #195 recommendation: accept | | Hello everyone, | | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a | newtype synonym `Code a`. The main change to the language is that the | special Template Haskell notation for typed splices will will work | with `Code a` rather than `Q (TExtp a)`. | | The benefit of having the newtype is that it makes it possible to | abstract over `Code`. For example, you can work with typed name | environments like `MapF Name Code`, where `MapF` is an "indexed" | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in | package `parameterized-utils` on hackage). | | Making typed TH work with `Code` directly avoids the need to | constantly switch between `Code` and `Q (TExp a)` and with the new | system users of typed TH are not likely to deal with the latter much | at all. | | For these reasons I recommend that we accept this proposal. Please | let me know if you think otherwise. | | -Iavor | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.orghttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkell.org&data=02%7C01%7Csimonpj%40microsoft.com%7C527240705f664101bba108d76295dabb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086268899169898&sdata=Hn9JTcGQkvhDnxdV%2FDQsDSB%2FsfzzQPKCQHXF3eItPmw%3D&reserved=0%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.comhttps://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7C527240705f664101bba108d76295dabb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086268899179890&sdata=19DoeBZc06cv4N%2BU8ZP7%2FQJNsSku7Rfo902SPB1aBOY%3D&reserved=0%7Ce2fd3cfd09334b865fb | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | ved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7C527240705f664101bba108d76295dabb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086268899189882&sdata=RB0VvVusRaa2rws1UZzuIg4TlM2gv42zPia3oNOO4T8%3D&reserved=0

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.orgmailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committeehttps://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%7C527240705f664101bba108d76295dabb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086268899189882&sdata=RB0VvVusRaa2rws1UZzuIg4TlM2gv42zPia3oNOO4T8%3D&reserved=0

I'm rather curious of what made my email sound like I was suggesting immediate acceptance, I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.” I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies. Simon From: Spiwack, Arnaud Sent: 06 November 2019 09:31 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better. For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread.

Those answers are helpful, yes, but I would want them incorporated in the proposal. And does Matt agree with these answers? Thanks for writing that up! Richard

On Nov 6, 2019, at 4:33 PM, Iavor Diatchki wrote:

Hello,

I thought my comment on GitHub answered Simon's questions, but Matt should indeed update the proposal to make it explicit. For the record here is how I think they should be answered:

* Is the data constructor Code visible to clients? Can they look inside the abstraction? - I think we should have a way to convert from `Code a` of a type `Q (TExp a)`. `fromCode :: Code a -> Q (TExp a)` - I don't think it matters very much if this is done with a function like that or by exposing thew newtype constructor. - My preference would be to keep `Code` abstract and have the function.

* unsafeQ lets you turn a Q (TExp a) into a Code a. But how can you get a Q (TExp a) in the first place? - I would imagine that you'd mostly get it out of `Code` using `fromCode`. - Another way would be to make it unsafely using the `TExp` constructor directly.

* Can you/should you be able to get a Q (TExp a) from a Code a? - Yes: it allows splicing typed code in untyped contexts which seems useful.

* The text says unsafeQ is added in order to perform unsafe Q actions inside of Code. So I was expecting something like unsafeAddQ :: Q () -> Code a -> Code a unsafeAddQThen :: Q a -> (a -> Code b) -> Code b

These can be defined using `fromCode` and `unsafeQ`. If you think they might be useful, we could probably add them to the TH modules. unsafeAddQ q c = unsafeQ (q >> fromCode c) unsafeAddQThen q k = unsafeQ (q >>= fromCode . k)

What do others think? Richard, you also had some questions but I am not sure what they are, does this help?

-Iavor

On Wed, Nov 6, 2019 at 1:35 AM Simon Peyton Jones via ghc-steering-committee wrote:

...

I'm rather curious of what made my email sound like I was suggesting immediate acceptance,

I just misinterpreted this: “This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.”

I understood you to mean “Let’s accept the proposal, if enough people have an accept vote, and leave it to the authors to sort out the details later”. But I obviously read too much into your words – apologies.

Simon

From: Spiwack, Arnaud Sent: 06 November 2019 09:31 To: Simon Peyton Jones Cc: Richard Eisenberg ; ghc-steering-committee Subject: Re: [ghc-steering-committee] #195 recommendation: accept

I don’t think we should formally accept proposals that are ill-specified, in the hope that they’ll subsequently be fixed up. Pushing back to “please revise to address these points” is not a negative thing – it’s a positive thing, saying good proposal but let’s make it better.

For the record: I didn't imply otherwise (I was merely registering my acceptance provided details are filled out to the rest of the committee's satisfaction). I'm rather curious of what made my email sound like I was suggesting immediate acceptance, but I really don't want to derail this thread.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

If there are no more issue to clear up, I'll mark this as accepted next week Monday. Please speak up, if you think otherwise. On Sat, Nov 9, 2019 at 7:22 PM Eric Seidel wrote:

I'm also in Arnaud's boat. I support improving the usability of Typed TH, and the Code newtype looks like a step in that direction. So, assuming we can satisfy Simon and Richard's questions, I support acceptance.

On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote:

...

I understand that some details are lacking. But I don't think, whatever the details are, that they will affect my opinion of the proposal: they are over my knowledge of Template Haskell.

This proposal seems well motivated. So, I'll count as an accept vote, when the details are eventually sorted out.

On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg wrote:

...

I'm in the same camp as Simon here -- I'm still a little murky on how `Code` will interact with `Q`.

Richard

...

On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering-committee wrote:

I'm basically supportive, but would like to see answers to my recent questions incorporated in the proposal before it is accepted. https://github.com/ghc-proposals/ghc-proposals/pull/195#issuecomment-5475225...

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 05 November 2019 16:44 | To: ghc-steering-committee | Subject: [ghc-steering-committee] #195 recommendation: accept | | Hello everyone, | | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` into a | newtype synonym `Code a`. The main change to the language is that the | special Template Haskell notation for typed splices will will work | with `Code a` rather than `Q (TExtp a)`. | | The benefit of having the newtype is that it makes it possible to | abstract over `Code`. For example, you can work with typed name | environments like `MapF Name Code`, where `MapF` is an "indexed" | variant of `Map` which maps `Name a` to `Code a` (`MapF` is defined in | package `parameterized-utils` on hackage). | | Making typed TH work with `Code` directly avoids the need to | constantly switch between `Code` and `Q (TExp a)` and with the new | system users of typed TH are not likely to deal with the latter much | at all. | | For these reasons I recommend that we accept this proposal. Please | let me know if you think otherwise. | | -Iavor | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | ved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

---

ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I wholeheartedly agree with Simon -- the proposal is not quite ready to accept, though we can signal to the author that we plan on accepting it once it's complete. Richard

On Nov 15, 2019, at 11:54 AM, Simon Peyton Jones via ghc-steering-committee wrote:

| If there are no more issue to clear up, I'll mark this as accepted | next week Monday. Please speak up, if you think otherwise.

I'm speaking up! Before accepting a proposal, we should be content that the proposal itself stands by itself. Our protocol says that we'll push back (promptly) to "Please revise", in the constructive spirit of "we are going to accept this but want you to make the proposal clear first".

This is not a big deal -- we are going to accept it! But I don’t want accept until the proposal is done.

Simon

| -----Original Message----- | From: ghc-steering-committee | On Behalf Of Iavor Diatchki | Sent: 15 November 2019 10:20 | To: Eric Seidel | Cc: ghc-steering-committee | Subject: Re: [ghc-steering-committee] #195 recommendation: accept | | If there are no more issue to clear up, I'll mark this as accepted | next week Monday. Please speak up, if you think otherwise. | | On Sat, Nov 9, 2019 at 7:22 PM Eric Seidel wrote: | > | > I'm also in Arnaud's boat. I support improving the usability of Typed | TH, and the Code newtype looks like a step in that direction. So, assuming | we can satisfy Simon and Richard's questions, I support acceptance. | > | > On Wed, Nov 6, 2019, at 03:46, Spiwack, Arnaud wrote: | > > I understand that some details are lacking. But I don't think, | whatever | > > the details are, that they will affect my opinion of the proposal: | they | > > are over my knowledge of Template Haskell. | > > | > > This proposal seems well motivated. So, I'll count as an accept vote, | > > when the details are eventually sorted out. | > > | > > On Tue, Nov 5, 2019 at 10:45 PM Richard Eisenberg | wrote: | > > > I'm in the same camp as Simon here -- I'm still a little murky on | how `Code` will interact with `Q`. | > > > | > > > Richard | > > > | > > > > On Nov 5, 2019, at 5:23 PM, Simon Peyton Jones via ghc-steering- | committee wrote: | > > > > | > > > > I'm basically supportive, but would like to see answers to my | recent questions incorporated in the proposal before it is accepted. | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fghc-proposals%2Fghc-proposals%2Fpull%2F195%23issuecomment- | 547522510&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=sFFuc3I0Tg2o6zhmji1SH6tYYwivp68IzQtPkL1P3aY%3D&reserved= | 0 | > > > > | > > > > Simon | > > > > | > > > > | > > > > | -----Original Message----- | > > > > | From: ghc-steering-committee | > > > > | On Behalf Of Iavor Diatchki | > > > > | Sent: 05 November 2019 16:44 | > > > > | To: ghc-steering-committee | > > > > | Subject: [ghc-steering-committee] #195 recommendation: accept | > > > > | | > > > > | Hello everyone, | > > > > | | > > > > | I am the shepherd for pull request #195 to wrap `Q (TExtp a)` | into a | > > > > | newtype synonym `Code a`. The main change to the language is | that the | > > > > | special Template Haskell notation for typed splices will will | work | > > > > | with `Code a` rather than `Q (TExtp a)`. | > > > > | | > > > > | The benefit of having the newtype is that it makes it possible | to | > > > > | abstract over `Code`. For example, you can work with typed name | > > > > | environments like `MapF Name Code`, where `MapF` is an | "indexed" | > > > > | variant of `Map` which maps `Name a` to `Code a` (`MapF` is | defined in | > > > > | package `parameterized-utils` on hackage). | > > > > | | > > > > | Making typed TH work with `Code` directly avoids the need to | > > > > | constantly switch between `Code` and `Q (TExp a)` and with the | new | > > > > | system users of typed TH are not likely to deal with the latter | much | > > > > | at all. | > > > > | | > > > > | For these reasons I recommend that we accept this proposal. | Please | > > > > | let me know if you think otherwise. | > > > > | | > > > > | -Iavor | > > > > | _______________________________________________ | > > > > | ghc-steering-committee mailing list | > > > > | ghc-steering-committee@haskell.org | > > > > | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | > > > > | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | > > > > | | committee&data=02%7C01%7Csimonpj%40microsoft.com%7Ce2fd3cfd09334b865fb | > > > > | | 308d7620f5a8c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085690437517 | > > > > | | 136&sdata=Qug9nwlVpQIY2U6jw%2FXKOnPpNPfiG6EAfWgv%2BTOJ4e0%3D&reser | > > > > | ved=0 | > > > > _______________________________________________ | > > > > ghc-steering-committee mailing list | > > > > ghc-steering-committee@haskell.org | > > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > > | > > > _______________________________________________ | > > > ghc-steering-committee mailing list | > > > ghc-steering-committee@haskell.org | > > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > _______________________________________________ | > > ghc-steering-committee mailing list | > > ghc-steering-committee@haskell.org | > > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | > > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee@haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225500 | 784&sdata=zpwr8CEI9XTSVr6wvaLJCHUnFEEESJBsPaxc%2BL3JNnI%3D&reserve | d=0 | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=02%7C01%7Csimonpj%40microsoft.com%7C50cf4370744148fa2ce | 908d769b577d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637094101225510 | 779&sdata=hd%2F%2Beh86VrymmU0pDgvtWz8iimoyppAywmkDDKZtE7U%3D&reser | ved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee