<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">I would have drafted a suggested change myself, but I wasn’t being difficult when I said that I didn’t understand the motivation. This whole conversation has really lost me.</p>
<p style="margin:0px 0px 1.2em!important">Regarding the proposed motivation: I think that 3) is irrelevant to our point. But 1) and 2) surprise me. I don’t believe that it’s the real motivation: “orthogonal things are controlled by separate flags” still reads pretty much as “because we can” to me. If it’s really the one motivation, fine, let’s write this (but then, I think that the current patch already contains more or less this argument). But if it really is the motivation, I find it incredibly weak. I don’t believe that it is though. Maybe the point is hinted in 2) there is a loss in expressiveness in the proposal, but it’s only one aspect of the proposal, and we want to isolate it, so that the backward-compatible part can benefit all. Is that a fair characterisation? I honestly don’t know</p>
<p style="margin:0px 0px 1.2em!important">This motivation that I drafted makes it sound like we are making a fork-like extension in OverloadedRecordUpdate. We’ve usually frowned upon fork-like extensions. Are we ok with this one?</p>
<p style="margin:0px 0px 1.2em!important">PS: I agree with Richard and Joachim, it ought to be documented. It also ought to be documented that it is a work in progress and positively <em>will</em> change in the next releases.</p>
<div title="MDH:PGRpdj5JIHdvdWxkIGhhdmUgZHJhZnRlZCBhIHN1Z2dlc3RlZCBjaGFuZ2UgbXlzZWxmLCBidXQg
SSB3YXNuJ3QgYmVpbmcgZGlmZmljdWx0IHdoZW4gSSBzYWlkIHRoYXQgSSBkaWRuJ3QgdW5kZXJz
dGFuZCB0aGUgbW90aXZhdGlvbi4gVGhpcyB3aG9sZSBjb252ZXJzYXRpb24gaGFzIHJlYWxseSBs
b3N0IG1lLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+UmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBt
b3RpdmF0aW9uOiBJIHRoaW5rIHRoYXQgMykgaXMgaXJyZWxldmFudCB0byBvdXIgcG9pbnQuIEJ1
dCAxKSBhbmQgMikgc3VycHJpc2UgbWUuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IGl0J3MgdGhlIHJl
YWwgbW90aXZhdGlvbjog4oCcb3J0aG9nb25hbCB0aGluZ3MgYXJlIGNvbnRyb2xsZWQgYnkgc2Vw
YXJhdGUgZmxhZ3PigJ0gc3RpbGwgcmVhZHMgcHJldHR5IG11Y2ggYXMg4oCcYmVjYXVzZSB3ZSBj
YW7igJ0gdG8gbWUuIElmIGl0J3MgcmVhbGx5IHRoZSBvbmUgbW90aXZhdGlvbiwgZmluZSwgbGV0
J3Mgd3JpdGUgdGhpcyAoYnV0IHRoZW4sIEkgdGhpbmsgdGhhdCB0aGUgY3VycmVudCBwYXRjaCBh
bHJlYWR5IGNvbnRhaW5zIG1vcmUgb3IgbGVzcyB0aGlzIGFyZ3VtZW50KS4gQnV0IGlmIGl0IHJl
YWxseSBpcyB0aGUgbW90aXZhdGlvbiwgSSBmaW5kIGl0IGluY3JlZGlibHkgd2Vhay4gSSBkb24n
dCBiZWxpZXZlIHRoYXQgaXQgaXMgdGhvdWdoLiBNYXliZSB0aGUgcG9pbnQgaXMgaGludGVkIGlu
IDIpIHRoZXJlIGlzIGEgbG9zcyBpbiBleHByZXNzaXZlbmVzcyBpbiB0aGUgcHJvcG9zYWwsIGJ1
dCBpdCdzIG9ubHkgb25lIGFzcGVjdCBvZiB0aGUgcHJvcG9zYWwsIGFuZCB3ZSB3YW50IHRvIGlz
b2xhdGUgaXQsIHNvIHRoYXQgdGhlIGJhY2t3YXJkLWNvbXBhdGlibGUgcGFydCBjYW4gYmVuZWZp
dCBhbGwuIElzIHRoYXQgYSBmYWlyIGNoYXJhY3RlcmlzYXRpb24/IEkgaG9uZXN0bHkgZG9uJ3Qg
a25vdzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhpcyBtb3RpdmF0aW9uIHRoYXQgSSBkcmFm
dGVkIG1ha2VzIGl0IHNvdW5kIGxpa2Ugd2UgYXJlIG1ha2luZyBhIGZvcmstbGlrZSBleHRlbnNp
b24gaW4gT3ZlcmxvYWRlZFJlY29yZFVwZGF0ZS4gV2UndmUgdXN1YWxseSBmcm93bmVkIHVwb24g
Zm9yay1saWtlIGV4dGVuc2lvbnMuIEFyZSB3ZSBvayB3aXRoIHRoaXMgb25lPzwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+UFM6IEkgYWdyZWUgd2l0aCBSaWNoYXJkIGFuZCBKb2FjaGltLCBpdCBv
dWdodCB0byBiZSBkb2N1bWVudGVkLiBJdCBhbHNvIG91Z2h0IHRvIGJlIGRvY3VtZW50ZWQgdGhh
dCBpdCBpcyBhIHdvcmsgaW4gcHJvZ3Jlc3MgYW5kIHBvc2l0aXZlbHkgX3dpbGxfIGNoYW5nZSBp
biB0aGUgbmV4dCByZWxlYXNlcy48YnI+PC9kaXY+PGJyPg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 4, 2021 at 10:39 AM Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div>
<p class="MsoNormal"><span>Arnaud<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>I’m all for improving the proposal. But rather than have the authors guess, can you be more specific about what you want?
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>To be concrete, do you want this (copied from up-thread) in the compare-one-vs-two subsection?<u></u><u></u></span></p>
<ol type="1" start="1">
<li>Add two extensions, as proposed here. Pro: flexibility for people like Iavor who want type-changing update, but would still like dot-notation. Pro: orthogonal things are controlled by separate flags. Con: each has to be documented
separately: two flags with one para each, instead of one flag with two paras. (The implementation cost is zero: it's only a question of which flag to test.)<u></u><u></u></li><li>Add one extension (OverloadedRecordFields, say) to do what OverloadedRecordDot and OverloadedRecordUpdate to in this proposal. Pro: only one extension. Con: some users might want dot-notation, but not want to give up type-changing
update.<u></u><u></u></li><li>Use RecordDotSyntax, and be prepared to change what it means (e.g. add NoFieldSelectors) later. Pro: only one extension. Con: changing the meaning of an extension will break programs.<u></u><u></u></li></ol>
<p class="MsoNormal"><span>Would adding that address your concern? Or did you have something else in mind?<u></u><u></u></span></p>
<p class="MsoNormal"><span><br>
Simon<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>>
<b>On Behalf Of </b>Spiwack, Arnaud<br>
<b>Sent:</b> 04 March 2021 09:22<br>
<b>To:</b> Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>><br>
<b>Cc:</b> Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>><br>
<b>Subject:</b> Re: [ghc-steering-committee] Modification to record dot syntax propsal<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I'm really the only one pushing back here. And since time is sort of of the essence, in this particular, I suppose that we can accept.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
Still, as I said in the Github thread, I would really appreciate a more fleshed out motivation to be documented in the proposal (in the alternatives subsection where the authors compare one vs two extensions). A proposal is for design documentation, and here,
the design decision can only be found in a Github thread. It would be much better if the proposal document reflected this thread.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
On Thu, Mar 4, 2021 at 2:18 AM Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-color:currentcolor currentcolor currentcolor rgb(204,204,204);border-style:none none none solid;border-width:medium medium medium 1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
I explicitly assent to accepting this revision. I agree with Arnaud and Richard that the motivation feels lacking, but we have enough precedent for fine-grained extensions that I feel comfortable with this as an implementation strategy.<br>
<br>
On Wed, Mar 3, 2021, at 11:04, Simon Peyton Jones via ghc-steering-committee wrote:<br>
> <br>
> In terms of actual official GHC Steering Committee business, this <br>
> proposal is really just about changing the name of the extension from <br>
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will <br>
> simply fall short of the entire proposal. Is that accurate?<br>
> <br>
> <br>
> <br>
> Not quite. <br>
> <br>
> * It replaces RecordDotSyntax with two separate extensions, <br>
> OverloadedRecordDot and OverloadedRecordUpdate.<br>
> * The second, OverloadedRecordUpdate would be advertised as <br>
> experimental and subject to change. (I’m totally happy with having it <br>
> in the user manual if that’s what everyone is happy with.)<br>
> * If you switch on experimental OverloadedRecordUpdate, you get the <br>
> whole proposal, with no falling short. But the committee has expressed <br>
> some second thoughts about update, hence advertising it as experimental.<br>
> OK? Only Richard, Iavor, Joachim, Arnaud have said anything on this <br>
> thread. I’m taking silence as assent … yell by the end of today if <br>
> you are unhappy. I’d like to communicate with the authors. <br>
> <br>
> <br>
> <br>
> Simon<br>
> <br>
> <br>
> <br>
> *From:* Richard Eisenberg <<a href="mailto:rae@richarde.dev" target="_blank">rae@richarde.dev</a>>
<br>
> *Sent:* 02 March 2021 16:46<br>
> *To:* Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.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 dot <br>
> syntax propsal<br>
> <br>
> <br>
> <br>
> I don't love having a feature that's completely unmentioned in the <br>
> manual -- too much of a root to trip over. (For example, tooling may <br>
> run into -XOverloadedRecordUpdate, but now has no official place to <br>
> look to see what it is.) I'd be fine with a short section in the manual <br>
> describing that an experimental -XOverloadedRecordUpdate extension <br>
> exists, is subject to change, and is meant to roughly implement some <br>
> part of some proposal. This can be done in just a few sentences, with a <br>
> link to the proposal, but just being silent seems unhelpful to users.<br>
> <br>
> <br>
> <br>
> With that small tweak, I'm quite happy to agree with the proposal here.<br>
> <br>
> <br>
> <br>
> In terms of actual official GHC Steering Committee business, this <br>
> proposal is really just about changing the name of the extension from <br>
> -XRecordDotSyntax to -XOverloadedRecordDot. The implementation will <br>
> simply fall short of the entire proposal. Is that accurate?<br>
> <br>
> <br>
> <br>
> Richard<br>
> <br>
> <br>
> <br>
> <br>
> > On Mar 2, 2021, at 7:45 AM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a>> wrote:<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 original proposal except for the extension name.<br>
> > * Record update will remain exactly as now, in 9.2; that is, drawing back from the original proposal.<br>
> > * There may be some *code* in 9.2 that allows overloaded record update, protected by OverloadedRecordUpdate, but not in the user manual, and not treated as an accepted proposal. I don’t think we should ask the authors to remove it, and it will allow
experimentation.<br>
> > * Adam is leading on a revised record-update proposal. This will cover<br>
> > * the tradeoffs between type-changing and non-type-changing update<br>
> > * what the current record-update syntax stands for, and/or any new syntax<br>
> > <br>
> <br>
> > Is that acceptable to everyone?<br>
> <br>
> > <br>
> <br>
> > Simon<br>
> <br>
> > <br>
> <br>
> > *From:* ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-bounces@haskell.org</a>> *On Behalf Of *Simon 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 <<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 syntax propsal<br>
> <br>
> > <br>
> <br>
> > I don't buy the argument of "this is already accepted", as I don't think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous decisions when we notice problems with them.<br>
> <br>
> > I agree in principle that we can revisit decisions. But we have to be aware that it is potentially very discouraging for proposal authors to<br>
> <br>
> > · propose something,<br>
> <br>
> > · have it *extensively* debated (including this very point), <br>
> <br>
> > · have it accepted,<br>
> <br>
> > · implement it,<br>
> <br>
> > and then be told that the committee has changed its mind. That’s pretty bad from their point of view.<br>
> <br>
> > <br>
> <br>
> > Still, Adam is working on a new SetField proposal, so perhaps that’s a 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>>; 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 syntax propsal<br>
> <br>
> > <br>
> <br>
> > Hello,<br>
> <br>
> > <br>
> <br>
> > I think there is a strong motivation to *at least* split the extensions: with the current design, enabling the special `.` notation also *disables* type changing record update, which has nothing to do with the `.` notation.<br>
> <br>
> > <br>
> <br>
> > My preference would be to:<br>
> <br>
> > 1. Split the original proposal into two parts: one about `.` notation, the other about record update (as suggested by this 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 have to choose between it and type changing record updates, which are quite 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 think many of us had noticed that part of the proposal (I certainly didn't), and I think we should be flexible enough to revisit previous 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 <<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 after Simon's recommendation), I have to admit: I am thoroughly confused. I'm not sure that two people in that thread have the same motivation, end goal, or design in mind.<br>
> <br>
> >> <br>
> <br>
> >> The motivations provided by the modified *Alternatives* section is not much more helpful (at the risk of caricaturing a little, it basically reads: “we made two extensions rather than one because we can”). Though it makes it clear that the end goal is
to fold a bunch of record-related extensions into one glorious record extension (well, probably not fold them, but make a meta-extension that implies all the 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 releases.<br>
> <br>
> >> <br>
> <br>
> >> Based on this, I don't care how this extension or the glorious record extension are named; but if we want to have two extensions we should have a serious reason. Right now, the one reason that I see (and Iavor raised), is that the update part of `RecordDotSyntax`
is not backward compatible. Is it a strong enough reason? I don't know. The only data point that I can provide is that when we discussed the original proposal, I brought it up several times, and it didn't seem very important at the time (the conversation focused
on other points of the proposal).<br>
> <br>
> >> <br>
> <br>
> >> So, I'm still reluctant. I feel that, at the very least, the motivations are not well-enough articulated in the proposal (I'll make a comment to this effect on Github when I'm done composing this email).<br>
> <br>
> >> <br>
> <br>
> >> I appreciate that I'm in the minority here. Yet, I'm still 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 <<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 though: we already have so many extensions. Are the reasons for this 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 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 notation, and one for overloaded update. Iavor likes the first but not the second. Neil likes both. Having separate extensions lets us experiment.<br>
> >>> <br>
> <br>
> >>> 1. You suggest that changing the definition of RecordDotSyntax in a subsequent release, e.g. by subsequently making it imply NoFieldSelectors, would be fine. But it certainly imposes pain – some programs would stop compiling. The approach offered by
this proposal avoids that problem.<br>
> >>> <br>
> <br>
> >>> Yes, there are lots of extensions surrounding records: NoFieldSelectors, DuplicateRecordFields, NamedFieldPuns, DisambiguateRecordFields, RecordWildCards. It may not be pretty to 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 <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank">ghc-steering-committee-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 dot syntax propsal<br>
> <br>
> >>> <br>
> <br>
> >>> <br>
> <br>
> >>>> I do think that reusing the record update syntax for the overloaded monomorphic update is a mistake---it is not something I had noticed during our original discussion.<br>
> <br>
> >>> <br>
> <br>
> >>> This is the one reason I can see for cutting this extension in smaller pieces. But, then again, -XOverloadedRecordUpdate would be a fork-like extension.<br>
> <br>
> >>> <br>
> <br>
> >>> Generally, I'm not in favour in proposals which split extensions though: we already have so many extensions. Are the reasons for this 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 finalised is a good reason, extensions mutate in their first 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>
> > <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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356690323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uuQ%2BWONzGX08Su2VfRDmoOXkMo0RjHEpIsIfE3zTwPs%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a> <<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%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356700318%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vUnHBFFzM0vAKHsOMUeKeTtes1C4qnJpEAfsbN%2FaPGM%3D&reserved=0" target="_blank">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%7Ccf65595be24d42cab2ca08d8dd9ab96c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637503003928846093%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3goska4aw00W0GxIvfDOj3JCdEaQ0CB8Zowb1u5RbMo%3D&reserved=0</a>><br>
> <br>
> <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.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%3D&reserved=0" target="_blank">
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><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.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cb9e5de3ee68046ca17e808d8deef1f43%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637504466356710308%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=NphMrHpqCq%2BBHniQiLFSBREpzr8e%2Bgdwgp9%2Bv5y6fAI%3D&reserved=0" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div>