<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-GB" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="mso-fareast-language:EN-US">Here’s the text <a href="https://docs.google.com/document/d/1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses/edit?usp=sharing">
https://docs.google.com/document/d/1GbWAC8URaVRmj6Lkj1b10okNsVuUfO6U0qq-lrSpses/edit?usp=sharing</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Spiwack, Arnaud <arnaud.spiwack@tweag.io>
<br>
<b>Sent:</b> 04 March 2021 15:29<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com><br>
<b>Cc:</b> Eric Seidel <eric@seidel.io>; ghc-steering-committee@haskell.org<br>
<b>Subject:</b> Re: [ghc-steering-committee] Modification to record dot syntax propsal<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
As for my part, Simon and I had a call and he cleared up the situation for me. We came up with a piece of text that we will offer to the other to explain the motivation behind the split. I am now fine with the change.<o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
<o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Thu, Mar 4, 2021 at 3:53 PM Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
| That being said, I don't see anything in the revised proposal about<br>
| the stability of OverloadedRecordUpdate. Are you saying that as part<br>
| of this revision, we'll explicitly accept OverloadedRecordDot and send<br>
| OverloadedRecordUpdate back for revision?<br>
<br>
We *already* accepted both, as part of accepting the earlier RecordDotSyntax proposal. But in this round, Iavor has pushed back against OverloadedRecordUpdate. No one else has expressed a view on this point.<br>
<br>
But rather than debate it at length I proposed to explicitly un-accept the OverloadedRecordUpdate part of the proposal. It'll return as part of a new record-update proposal that Adam is working on.<br>
<br>
In the meantime OverloadedRecordUpdate will be in GHC's codebase, and (assuming that's what the majority wants) documented in the user manual, with a prominent "may change" caveat.<br>
<br>
Does that make it clear?<br>
<br>
Simon <br>
<br>
| -----Original Message-----<br>
| From: ghc-steering-committee <ghc-steering-committee-<br>
| <a href="mailto:bounces@haskell.org" target="_blank">bounces@haskell.org</a>> On Behalf Of Eric Seidel<br>
| Sent: 04 March 2021 14:38<br>
| To: <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
| Subject: Re: [ghc-steering-committee] Modification to record dot<br>
| syntax propsal<br>
| <br>
| I agree with Richard and Joachim that it should be documented in the<br>
| user guide. It's much better to document features with the expected<br>
| level of support than to let users stumble upon them and make their<br>
| own assumptions about stability.<br>
| <br>
| That being said, I don't see anything in the revised proposal about<br>
| the stability of OverloadedRecordUpdate. Are you saying that as part<br>
| of this revision, we'll explicitly accept OverloadedRecordDot and send<br>
| OverloadedRecordUpdate back for revision?<br>
| <br>
| On Thu, Mar 4, 2021, at 04:46, Simon Peyton Jones via ghc-steering-<br>
| committee wrote:<br>
| ><br>
| > Friends<br>
| ><br>
| ><br>
| ><br>
| > We've agree to accept my suggestion below.<br>
| ><br>
| ><br>
| ><br>
| > But there is one point at issue: should OverloadedRecordUpdate be<br>
| > documented in the user manual, albeit identified as a not-yet-<br>
| accepted<br>
| > feature?<br>
| ><br>
| ><br>
| ><br>
| > * Richard positively wants it in the manual<br>
| > * Iavor positively doesn't want it there.<br>
| ><br>
| ><br>
| > I don't mind either way.<br>
| ><br>
| ><br>
| ><br>
| > What do others think? It's not a big deal, but we owe the authors a<br>
| > decision. Answer by the end of the week please, and I'll make a<br>
| > shepherd decision based on the opinions I get.<br>
| ><br>
| ><br>
| ><br>
| > Simon<br>
| ><br>
| ><br>
| ><br>
| ><br>
| ><br>
| > *From:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
| > *Sent:* 02 March 2021 12:45<br>
| > *To:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
| > *Cc:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
| > *Subject:* RE: [ghc-steering-committee] Modification to record dot<br>
| > syntax propsal<br>
| ><br>
| ><br>
| ><br>
| > Friends<br>
| ><br>
| ><br>
| ><br>
| > Having consulted the authors, I propose that we do this:<br>
| ><br>
| ><br>
| ><br>
| > * Proceed with OverloadedRecordDot for 9.2, exactly as in the<br>
| > original proposal except for the extension name.<br>
| > * Record update will remain exactly as now, in 9.2; that is,<br>
| drawing<br>
| > back from the original proposal.<br>
| > * There may be some *code* in 9.2 that allows overloaded record<br>
| > update, protected by OverloadedRecordUpdate, but not in the user<br>
| > manual, and not treated as an accepted proposal. I don't think we<br>
| > should ask the authors to remove it, and it will allow<br>
| experimentation.<br>
| > * Adam is leading on a revised record-update proposal. This will<br>
| cover<br>
| > * the tradeoffs between type-changing and non-type-changing<br>
| update<br>
| > * what the current record-update syntax stands for, and/or any<br>
| new<br>
| > syntax<br>
| ><br>
| ><br>
| > Is that acceptable to everyone?<br>
| ><br>
| ><br>
| ><br>
| > Simon<br>
| ><br>
| ><br>
| ><br>
| > *From:* ghc-steering-committee<br>
| > <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> *On Behalf Of *Simon<br>
| > Peyton Jones via ghc-steering-committee<br>
| > *Sent:* 01 March 2021 17:51<br>
| > *To:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>>; Spiwack, Arnaud<br>
| > <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>><br>
| > *Cc:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
| > *Subject:* Re: [ghc-steering-committee] Modification to record dot<br>
| > syntax propsal<br>
| ><br>
| ><br>
| ><br>
| > I don't buy the argument of "this is already accepted", as I don't<br>
| > think many of us had noticed that part of the proposal (I certainly<br>
| > didn't), and I think we should be flexible enough to revisit<br>
| previous<br>
| > decisions when we notice problems with them.<br>
| ><br>
| > I agree in principle that we can revisit decisions. But we have to<br>
| be<br>
| > aware that it is potentially very discouraging for proposal authors<br>
| to<br>
| ><br>
| > * propose something,<br>
| > * have it *extensively* debated (including this very point),<br>
| > * have it accepted,<br>
| > * implement it,<br>
| > and then be told that the committee has changed its mind. That's<br>
| > pretty bad from their point of view.<br>
| ><br>
| ><br>
| ><br>
| > Still, Adam is working on a new SetField proposal, so perhaps that's<br>
| a<br>
| > figleaf. I'll consult them.<br>
| ><br>
| ><br>
| > Simon<br>
| ><br>
| ><br>
| ><br>
| ><br>
| ><br>
| > *From:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br>
| > *Sent:* 01 March 2021 17:23<br>
| > *To:* Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>><br>
| > *Cc:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>>;<br>
| > ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
| > *Subject:* Re: [ghc-steering-committee] Modification to record dot<br>
| > syntax propsal<br>
| ><br>
| ><br>
| ><br>
| > Hello,<br>
| ><br>
| ><br>
| ><br>
| > I think there is a strong motivation to *at least* split the<br>
| > extensions: with the current design, enabling the special `.`<br>
| notation<br>
| > also *disables* type changing record update, which has nothing to do<br>
| > with the `.` notation.<br>
| ><br>
| ><br>
| ><br>
| > My preference would be to:<br>
| ><br>
| > 1. Split the original proposal into two parts: one about `.`<br>
| > notation, the other about record update (as suggested by this<br>
| proposal)<br>
| ><br>
| > 2. Treat the `.` notation part as accepted<br>
| ><br>
| > 3. Require changes on the record update part, so that you don't<br>
| have<br>
| > to choose between it and type changing record updates, which are<br>
| quite<br>
| > useful, and I don't think we should aim for a Haskell without them.<br>
| ><br>
| ><br>
| ><br>
| > I don't buy the argument of "this is already accepted", as I don't<br>
| > think many of us had noticed that part of the proposal (I certainly<br>
| > didn't), and I think we should be flexible enough to revisit<br>
| previous<br>
| > decisions when we notice problems with them.<br>
| ><br>
| ><br>
| ><br>
| > -Iavor<br>
| ><br>
| ><br>
| ><br>
| ><br>
| ><br>
| ><br>
| ><br>
| > On Mon, Mar 1, 2021 at 1:40 AM Spiwack, Arnaud<br>
| <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
| ><br>
| > > Simon, all,<br>
| ><br>
| > ><br>
| ><br>
| > > After reading more of the PR thread (in particular the fews posts<br>
| after Simon's recommendation), I have to admit: I am thoroughly<br>
| confused. I'm not sure that two people in that thread have the same<br>
| motivation, end goal, or design in mind.<br>
| ><br>
| > ><br>
| ><br>
| > > The motivations provided by the modified *Alternatives* section is<br>
| not much more helpful (at the risk of caricaturing a little, it<br>
| basically reads: "we made two extensions rather than one because we<br>
| can"). Though it makes it clear that the end goal is to fold a bunch<br>
| of record-related extensions into one glorious record extension (well,<br>
| probably not fold them, but make a meta-extension that implies all the<br>
| extensions that we've decided we like).<br>
| ><br>
| > ><br>
| ><br>
| > > My starting point is that:<br>
| ><br>
| > > - Additional extensions have a maintenance cost<br>
| ><br>
| > > - Additional extensions impose a cognitive burden on their use<br>
| ><br>
| > > - I expect that a new extension will break my code in the next few<br>
| releases.<br>
| ><br>
| > ><br>
| ><br>
| > > Based on this, I don't care how this extension or the glorious<br>
| record extension are named; but if we want to have two extensions we<br>
| should have a serious reason. Right now, the one reason that I see<br>
| (and Iavor raised), is that the update part of `RecordDotSyntax` is<br>
| not backward compatible. Is it a strong enough reason? I don't know.<br>
| The only data point that I can provide is that when we discussed the<br>
| original proposal, I brought it up several times, and it didn't seem<br>
| very important at the time (the conversation focused on other points<br>
| of the proposal).<br>
| ><br>
| > ><br>
| ><br>
| > > So, I'm still reluctant. I feel that, at the very least, the<br>
| motivations are not well-enough articulated in the proposal (I'll make<br>
| a comment to this effect on Github when I'm done composing this<br>
| email).<br>
| ><br>
| > ><br>
| ><br>
| > > I appreciate that I'm in the minority here. Yet, I'm still<br>
| unconvinced.<br>
| ><br>
| > ><br>
| ><br>
| > > Best,<br>
| ><br>
| > > Arnaud<br>
| ><br>
| > ><br>
| ><br>
| > > On Sat, Feb 27, 2021 at 12:39 AM Simon Peyton Jones<br>
| <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
| ><br>
| > >> Generally, I'm not in favour in proposals which split extensions<br>
| though: we already have so many extensions. Are the reasons for this<br>
| split strong enough? I haven't had time to dig into the details.<br>
| ><br>
| > >> Arnaud, happily, you don't have to dig very deep - just read the<br>
| handful of posts following my recommendation.<br>
| ><br>
| > >><br>
| ><br>
| > >> There seem to be two motivations.<br>
| ><br>
| > >><br>
| ><br>
| > >> 1. There really are two orthogonal extensions, one for r.x<br>
| notation, and one for overloaded update. Iavor likes the first but<br>
| not the second. Neil likes both. Having separate extensions lets us<br>
| experiment.<br>
| > >><br>
| ><br>
| > >> 1. You suggest that changing the definition of RecordDotSyntax<br>
| in a subsequent release, e.g. by subsequently making it imply<br>
| NoFieldSelectors, would be fine. But it certainly imposes pain - some<br>
| programs would stop compiling. The approach offered by this proposal<br>
| avoids that problem.<br>
| > >><br>
| ><br>
| > >> Yes, there are lots of extensions surrounding records:<br>
| NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns,<br>
| DisambiguateRecordFields, RecordWildCards. It may not be pretty to<br>
| divide things up so fine, but it's not new.<br>
| ><br>
| > >><br>
| ><br>
| > >><br>
| ><br>
| > >> If there are alternative suggestions, let's hear them.<br>
| ><br>
| > >><br>
| ><br>
| > >> Simon<br>
| ><br>
| > >><br>
| ><br>
| > >> *From:* ghc-steering-committee <ghc-steering-committee-<br>
| <a href="mailto:bounces@haskell.org" target="_blank">bounces@haskell.org</a>> *On Behalf Of *Spiwack, Arnaud<br>
| > >> *Sent:* 26 February 2021 22:33<br>
| > >> *To:* Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" target="_blank">iavor.diatchki@gmail.com</a>><br>
| > >> *Cc:* ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
| > >> *Subject:* Re: [ghc-steering-committee] Modification to record<br>
| dot syntax propsal<br>
| ><br>
| > >><br>
| ><br>
| > >><br>
| ><br>
| > >>> I do think that reusing the record update syntax for the<br>
| overloaded monomorphic update is a mistake---it is not something I had<br>
| noticed during our original discussion.<br>
| ><br>
| > >><br>
| ><br>
| > >> This is the one reason I can see for cutting this extension in<br>
| smaller pieces. But, then again, -XOverloadedRecordUpdate would be a<br>
| fork-like extension.<br>
| ><br>
| > >><br>
| ><br>
| > >> Generally, I'm not in favour in proposals which split extensions<br>
| though: we already have so many extensions. Are the reasons for this<br>
| split strong enough? I haven't had time to dig into the details.<br>
| ><br>
| > >><br>
| ><br>
| > >> I'm not sure that not having the design of the proposal quite<br>
| finalised is a good reason, extensions mutate in their first<br>
| iterations, I don't think that it's a problem.<br>
| ><br>
| > _______________________________________________<br>
| > ghc-steering-committee mailing list<br>
| > <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
| ><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>
| .<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977282748%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mJwXqs%2FBs3qhnroUA%2FHLmBF8Y2hgNf8Ha65v%2BuWWotI%3D&reserved=0" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>
| committee&data=04%7C01%7Csimonpj%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977292739%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2B7yr5Qa%2FcqrDvM6f0WeNaZt1ub3o%2Bj0SGjFeX2ASFXw%3D&reserved=0" target="_blank">40microsoft.com</a>%7C8abc00434aa94b7<br>
| fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046<br>
| 55938142566%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9DGVl6oJc0%2BIQekuXf<br>
| zwqviiaT%2FaHZIlIk3R5aMZssA%3D&reserved=0<br>
| ><br>
| _______________________________________________<br>
| ghc-steering-committee mailing list<br>
| <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" target="_blank">
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>
| .<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8851cSrXEPVuoeqJJlFtCM%2BVNJhT%2BhvPXfmTY9sm4mk%3D&reserved=0" target="_blank">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>
| committee&data=04%7C01%7Csimonpj%<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977302733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=d1brPSssIphSkd1RwlnV%2Bj%2FotGv5Czxv1kYLkxBzUoE%3D&reserved=0" target="_blank">40microsoft.com</a>%7C8abc00434aa94b7<br>
| fa98e08d8df1b5d9f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6375046<br>
| 55938152562%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>
| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QZlV0RrRttaiDdrQNiRB<br>
| vUhS6il1DydPX5cyl%2BdILbI%3D&reserved=0<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="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%7Cc9fd0d48bfb0488ab1f208d8df225bdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504685977312732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eqlY43l%2Bma8Vl3hQt6gqWmdUEkGF9xkCMbbBvcbK40w%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>