<div dir="ltr"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I don’t think we were finished<br>
with bikeshedding the syntax. At least I think the proposal should state what<br>
the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub<br>
thread.
</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">OK -- but I suspect that most of us have lost context.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Would you like to post (on the Github) a message explaining:</div><ul><li style="font-family:tahoma,sans-serif" class="gmail_default">what the syntactic alternatives are</li><li style="font-family:tahoma,sans-serif" class="gmail_default">what you recommend</li></ul><div style="font-family:tahoma,sans-serif" class="gmail_default">That will help to focus the discussion</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Thanks!</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 7 Feb 2025 at 12:16, Malte Ott <<a href="mailto:malte.ott@maralorn.de">malte.ott@maralorn.de</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">I do not object to accepting the proposal, but I don’t think we were finished<br>
with bikeshedding the syntax. At least I think the proposal should state what<br>
the syntax is when ImportQualifiedPost is enabled and voiced that on the GitHub<br>
thread.<br>
<br>
I know we all dread wasting our time with syntax discussions but lets at least<br>
think about it for 5 minutes.<br>
<br>
Best,<br>
Malte<br>
<br>
On 2025-02-07 15:48, Arnaud Spiwack wrote:<br>
> Ok, we have enough of a quorum at this point. If everybody else voted 1<br>
> extension this would come at a rough draw. It can't be a strong enough<br>
> push to overrule the preference of the authors.<br>
> <br>
> I'll give it a handful more day, say until next Wednesday 12th<br>
> February. If someone has a strong objection, please voice it very<br>
> loudly. Otherwise I'll declare the proposal as accepted in its current<br>
> state.<br>
> <br>
> Best,<br>
> Arnaud<br>
> <br>
> On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo<br>
> <[1]<a href="mailto:erikd@mega-nerd.com" target="_blank">erikd@mega-nerd.com</a>> wrote:<br>
> <br>
> OK, slightly in favor of two extensions.<br>
> <br>
> Erik<br>
> <br>
> Erik de Castro Lopo wrote:<br>
> <br>
> > Hi,<br>
> ><br>
> > I have read through the proposal, but there is something I am<br>
> still unsure<br>
> > of. For the LANGUAGE pragma's is there any utility in using one<br>
> separately<br>
> > form the other? It seems there isn't. In any one file you would<br>
> use either<br>
> > one or the other.<br>
> ><br>
> > Thanks,<br>
> > Erik<br>
> ><br>
> > Arnaud Spiwack wrote:<br>
> ><br>
> > > Sorry I disappeared for a while. I second Simon's call, let's<br>
> vote. Let me<br>
> > > repost a link to Simon's pro and cons post<br>
> > ><br>
> [2]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm</a><br>
> ent-2609199731<br>
> > ><br>
> > > So far, we have the following votes<br>
> > ><br>
> > > - Simon: 1 extension<br>
> > > - Adam: 2 extension (feels quite strongly about it)<br>
> > > - Sebastian: 1 extension (on the Github thread, but I'll count<br>
> it as a vote<br>
> > > anyway)<br>
> > ><br>
> > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?<br>
> > ><br>
> > > ---<br>
> > ><br>
> > > Beyond that we have a single piece of community feedback on the<br>
> Github<br>
> > > thread. It's from Michael Peyton Jones who is in favour of 2<br>
> extensions,<br>
> > > find it here<br>
> > ><br>
> [3]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm</a><br>
> ent-2609583126<br>
> > ><br>
> > > ---<br>
> > ><br>
> > > For the record, I hadn't commented about it in my<br>
> recommendation, despite<br>
> > > my well-known and desperately public distaste for micro<br>
> extensions. I have<br>
> > > a couple of reasons:<br>
> > > - I dislike micro-extensions less now that we are doing the<br>
> GHC20XX (the<br>
> > > last one was very modest, I'm in favour, by the way, of doing a<br>
> much more<br>
> > > ambitious language edition soon, otherwise my distaste will come<br>
> back with<br>
> > > a vengeance)<br>
> > > - While I consider every proposal with several extensions in it<br>
> with<br>
> > > suspicion, the authors did argue for their second extension, I<br>
> found the<br>
> > > argument mildly convincing, and thought it wasn't worth fighting<br>
> against.<br>
> > ><br>
> > > Now, even like this my preference is mildly for one extension.<br>
> Adam says<br>
> > > that it's easier to implement warnings with both the new syntax<br>
> on and<br>
> > > implicit stage persistence left turned on, than to implement<br>
> errors when<br>
> > > implicit stage persistence is turned off. It may be so, but I<br>
> don't think<br>
> > > we can avoid implementing the errors anyway, so I don't feel<br>
> that it's a<br>
> > > particularly compelling argument. I don't feel strongly. But<br>
> that's<br>
> > > presumably where my vote goes.<br>
> > ><br>
> > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones<br>
> <[4]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > > Yes: all members of the steering committee, please vote.<br>
> Evaluating<br>
> > > > proposals is what we all signed up to do!<br>
> > > ><br>
> > > > Thanks<br>
> > > ><br>
> > > > Simon<br>
> > > ><br>
> > > > On Mon, 3 Feb 2025 at 20:45, Adam Gundry<br>
> <[5]<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a>> wrote:<br>
> > > ><br>
> > > >> I'm (unsurprisingly) in favour of acceptance, and I vote for<br>
> two<br>
> > > >> extensions. As I commented on the GitHub thread:<br>
> > > >><br>
> > > >> > We shouldn't unnecessarily conflate a syntactic extension<br>
> > > >> (ExplicitLevelImports) with a semantic one<br>
> (NoImplicitStagePersistence)<br>
> > > >> just because the common case is to want both and we want to<br>
> keep the<br>
> > > >> number of extensions lower.<br>
> > > >><br>
> > > >> If there are reasons why having two extensions is actually<br>
> problematic,<br>
> > > >> I'd like to hear them.<br>
> > > >><br>
> > > >> Also, at the risk of opening another avenue of discussion, we<br>
> also need<br>
> > > >> to resolve the syntax question (see<br>
> > > >><br>
> > > >><br>
> [6]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio</a><br>
> n_r1849123243).<br>
> > > >><br>
> > > >> I don't have a very strong opinion here, but given that some<br>
> people do,<br>
> > > >> perhaps we should make ImportQualifiedPost affect splice<br>
> imports so we<br>
> > > >> have<br>
> > > >><br>
> > > >> import splice qualified A -- By default<br>
> > > >> import A splice qualified -- Under ImportQualifiedPost<br>
> > > >><br>
> > > >> In any case, please do vote! It would be good to get this<br>
> proposal done.<br>
> > > >><br>
> > > >> Cheers,<br>
> > > >><br>
> > > >> Adam<br>
> > > >><br>
> > > >><br>
> > > >><br>
> > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote:<br>
> > > >> > Arnaud<br>
> > > >> ><br>
> > > >> > OK, following my call and some further iteration, the<br>
> proposal is much<br>
> > > >> > improved. See here<br>
> > > >> ><br>
> <[7]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a>>.<br>
> Please<br>
> > > >> read<br>
> > > >> > the new "Proposed Change Specification" which has had a<br>
> large rewrite.<br>
> > > >> ><br>
> > > >> > I vote to accept.<br>
> > > >> ><br>
> > > >> > BUT there is one point that the committee must resolve:<br>
> *one extension<br>
> > > >> > of two?* It's just a judgement call and I lay out the<br>
> choices in this<br>
> > > >> > post<br>
> > > >> > <<br>
> > > >><br>
> [8]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm</a><br>
> ent-2609199731>.<br>
> > > >> I doubt that we'll get much community feedback. I suggest<br>
> that we just<br>
> > > >> vote. I vote for one, not two. As does Sebastian.<br>
> > > >> ><br>
> > > >> > Over to you Arnaud. Let's get this one done. Matthew is<br>
> busy<br>
> > > >> > implementing it for a customer and it has been on our to-do<br>
> list for<br>
> > > >> > some time now. (Partly my fault.)<br>
> > > >> ><br>
> > > >> > Simon<br>
> > > >> ><br>
> > > >> > On Tue, 21 Jan 2025 at 10:48, Simon Peyton Jones<br>
> > > >> > <[9]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> <mailto:[10]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>><br>
> > > >> wrote:<br>
> > > >> ><br>
> > > >> > Matthew and I had a good conversation. Some notes here<br>
> > > >> > <<br>
> > > >><br>
> [11]<a href="https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R</a><br>
> Phk5MslruY7yXD0/edit?usp=sharing<br>
> > > >> >.<br>
> > > >> ><br>
> > > >> > He's going to work on a revision to the proposal which<br>
> I'll iterate<br>
> > > >> > with him.<br>
> > > >> ><br>
> > > >> > Simon<br>
> > > >> ><br>
> > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack<br>
> > > >> > <[12]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> <mailto:[13]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>> wrote:<br>
> > > >> ><br>
> > > >> > Then, let's wait until your call with Matthew and<br>
> decide how to<br>
> > > >> > act then.<br>
> > > >> ><br>
> > > >> > On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones<br>
> > > >> > <[14]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> > > >> > <mailto:[15]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>>> wrote:<br>
> > > >> ><br>
> > > >> > Arnaud<br>
> > > >> ><br>
> > > >> > I have responded with a lot of feedback on the<br>
> Github thread<br>
> > > >> > <<br>
> > > >><br>
> [16]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ</a><br>
> estreview-2562175116<br>
> > > >> >.<br>
> > > >> ><br>
> > > >> > TL:DR: I like the direction of travel but have<br>
> too many<br>
> > > >> > questions of detail to be ready to accept it<br>
> just yet.<br>
> > > >> ><br>
> > > >> > I have arranged a call with Matthew.<br>
> > > >> ><br>
> > > >> > Simon<br>
> > > >> ><br>
> > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack<br>
> > > >> > <[17]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> <mailto:[18]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>><br>
> > > >> > wrote:<br>
> > > >> ><br>
> > > >> ><br>
> > > >> > Mathew Pickering, Rodrigo Mesquita, and our<br>
> own Adam<br>
> > > >> > Gundry put forward a new proposal for the<br>
> perenial<br>
> > > >> > problem of dependencies and Template<br>
> Haskell<br>
> > > >> ><br>
> [19]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a><br>
> > > >> > <<br>
> > > >> [20]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a>><br>
> > > >> ><br>
> > > >> > I've got to be honest, I'm not fully<br>
> convinced by the<br>
> > > >> > proposal. More on that in a minute, but it<br>
> learns a<br>
> > > >> > lesson from previous attempts at the same<br>
> problem by<br>
> > > >> > solving the absolute minimal problem, but<br>
> this leads to<br>
> > > >> > a somewhat fork-like situation for which it<br>
> isn't clear<br>
> > > >> > whether it will be resolved in the future.<br>
> That being<br>
> > > >> > said, it solves a real problem which has<br>
> plagued GHC<br>
> > > >> > compilation forever. And I'm inclined to<br>
> believe that we<br>
> > > >> > can't really do much better.<br>
> > > >> ><br>
> > > >> > But I'm getting ahead of myself. The<br>
> problem is that<br>
> > > >> > when you have -XTemplateHaskell in a file,<br>
> all the<br>
> > > >> > dependencies' compiled code must suddenly<br>
> be available<br>
> > > >> > for typechecking. This breaks `-fno-code`<br>
> and wounds<br>
> > > >> > recompilation avoidance. This is probably<br>
> the main<br>
> > > >> > reason why it's a widely held belief that<br>
> Template<br>
> > > >> > Haskell is slow: you use Template Haskell<br>
> in a few<br>
> > > >> > modules, and suddenly your IDE is much less<br>
> responsive<br>
> > > >> > and you recompile more files. Yay?<br>
> > > >> ><br>
> > > >> > Anyway, the general gist of the solution is<br>
> clear: we<br>
> > > >> > must be able to specify that we don't want<br>
> to import a<br>
> > > >> > module for Template Haskell (there is<br>
> subtleties in this<br>
> > > >> > too as you will want a little more control<br>
> than that for<br>
> > > >> > cross-compilation reasons which I'm not<br>
> competent about<br>
> > > >> > to comment on). But the devil is in the<br>
> many details.<br>
> > > >> > There's this thing called implicit<br>
> cross-stage<br>
> > > >> > persistence which says that anything you<br>
> import<br>
> > > >> > not-for-template-haskell is going to be<br>
> available in<br>
> > > >> > quotes and splices anyway. Sigh… So you<br>
> have to turn<br>
> > > >> > this off. This is what the proposal does.<br>
> And pretty<br>
> > > >> > much only.<br>
> > > >> ><br>
> > > >> > They introduce a new<br>
> > > >> > extension-XNoImplicitStagePersistence which<br>
> disables<br>
> > > >> > that, and a little bit of syntax to specify<br>
> the stage of<br>
> > > >> > imports. That's it.<br>
> > > >> ><br>
> > > >> > But it comes with severe limitations, most<br>
> importantly:<br>
> > > >> > you can't ever use a symbol defined in the<br>
> current<br>
> > > >> > module in a quote or splice of this current<br>
> module,<br>
> > > >> > typed template Haskell is turned off.<br>
> > > >> ><br>
> > > >> > For these situations, the proposal kind of<br>
> advertises<br>
> > > >> > using `-XImplicitStagePersistence`. Which<br>
> does seem like<br>
> > > >> > a fork-like situation to me. Not cool. Yet…<br>
> yet Template<br>
> > > >> > Haskell is a big messy ball of yarn, and I<br>
> don't think<br>
> > > >> > it's fair to ask of any proposal to<br>
> entangle it<br>
> > > >> > completely. The failure of past attempts<br>
> seem to support<br>
> > > >> > this case. And I believe the authors are<br>
> correct when<br>
> > > >> > they claim that this proposal, in practice,<br>
> covers a<br>
> > > >> > vast majority of the uses of Template<br>
> Haskell out there.<br>
> > > >> > So maybe we can see that as a new<br>
> foundation for<br>
> > > >> > Template Haskell. I'm not thrilled about<br>
> it, but it's<br>
> > > >> > probably the most reasonable way forward.<br>
> > > >> ><br>
> > > >> > The real problem with this sort of proposal<br>
> is that then<br>
> > > >> > I get to write way too long an email to the<br>
> committee.<br>
> > > >> > Hopefully this didn't deter you. Read the<br>
> proposal, and<br>
> > > >> > let's vote.<br>
> > > >> ><br>
> > > >> > --<br>
> > > >> > Arnaud Spiwack<br>
> > > >> > Director, Research at<br>
> [21]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a><br>
> > > >> > <[22]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a>> and<br>
> [23]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a><br>
> > > >> > <[24]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>>.<br>
> > > >><br>
> > > >><br>
> > > >> --<br>
> > > >> Adam Gundry, Haskell Consultant<br>
> > > >> Well-Typed LLP, [25]<a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
> > > >><br>
> > > >> Registered in England & Wales, OC335890<br>
> > > >> 27 Old Gloucester Street, London WC1N 3AX, England<br>
> > > >><br>
> > > >> _______________________________________________<br>
> > > >> ghc-steering-committee mailing list<br>
> > > >> [26]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > >><br>
> [27]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c</a><br>
> ommittee<br>
> > > >><br>
> > > > _______________________________________________<br>
> > > > ghc-steering-committee mailing list<br>
> > > > [28]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> > > ><br>
> [29]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c</a><br>
> ommittee<br>
> > > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Arnaud Spiwack<br>
> > > Director, Research at [30]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
> [31]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> ><br>
> ><br>
> > --<br>
> ><br>
> --------------------------------------------------------------------<br>
> --<br>
> > Erik de Castro Lopo<br>
> > [32]<a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
> ><br>
> <br>
> --<br>
> --------------------------------------------------------------------<br>
> --<br>
> Erik de Castro Lopo<br>
> [33]<a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> [34]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> [35]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c</a><br>
> ommittee<br>
> <br>
> --<br>
> <br>
> Arnaud Spiwack<br>
> Director, Research at [36]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
> [37]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> <br>
> References<br>
> <br>
> 1. mailto:<a href="mailto:erikd@mega-nerd.com" target="_blank">erikd@mega-nerd.com</a><br>
> 2. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731</a><br>
> 3. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126</a><br>
> 4. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> 5. mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
> 6. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243</a><br>
> 7. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a><br>
> 8. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731</a><br>
> 9. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> 10. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> 11. <a href="https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing</a><br>
> 12. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> 13. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> 14. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> 15. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
> 16. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116</a><br>
> 17. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> 18. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
> 19. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a><br>
> 20. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682</a><br>
> 21. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
> 22. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
> 23. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
> 24. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
> 25. <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
> 26. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> 27. <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> 28. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> 29. <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> 30. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
> 31. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
> 32. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
> 33. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
> 34. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> 35. <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> 36. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
> 37. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" 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://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>