<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or<br>
something similar and then treat splice exactly as qualified.<br>
Seeing that that’s much too much trouble I would consider doing that but not<br>
changing the extension name.</blockquote><div><br></div><div>(aside: with ImportQualifiedPost turned, both the `qualified` keyword before and the `qualified` keyword after are accepted).</div><div><br></div><div>---</div><div><br></div><div>Nobody seems to have an opinion. Owing to various illnesses traversing my households (and my lungs…) this week, I let that slide a bit longer than I wanted. But anyway. I'll interpret silence as assent, and mark the proposal as accepted. We've waited too long already.<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 3 Mar 2025 at 19:03, 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 for my part are kinda dissatisfied by both options.<br>
And I am very much sympathetic to the position that a committee shouldn’t settle<br>
alternatives by allowing all of them.<br>
That being said I am still in favor of leaving the proposal like it is now, which is (B).<br>
<br>
My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or<br>
something similar and then treat splice exactly as qualified.<br>
Seeing that that’s much too much trouble I would consider doing that but not<br>
changing the extension name.<br>
<br>
I can also see the reasoning that we should just go with (A) now without<br>
blocking the proposal any longer because it will always be possible to convert<br>
it to (B) later.<br>
<br>
Best<br>
Malte<br>
<br>
On 2025-03-03 15:52, Arnaud Spiwack wrote:<br>
>    There may have been delivery issues last week to the committee mailing<br>
>    list. Did everybody get this email by Simon and mine below?<br>
> <br>
>    On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones<br>
>    <[1]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> <br>
>    Syntax is always troublesome, and best resolved by a vote.  I think you<br>
>    are asking us to vote on:<br>
>      * (A) splice/quote keywords only before the module name<br>
>      * (B) splice/quote keywords either before or after the module name<br>
> <br>
>    I vote (A).  My opinion is not a strong one.  Let's see what other<br>
>    committee members think.  RSVP<br>
> <br>
>    Simon<br>
> <br>
>    On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack<br>
>    <[2]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
> <br>
>    So, let me recap the situation.<br>
> <br>
>    The authors favourite syntax is<br>
>       `import splice A`<br>
>       `import quote B`<br>
> <br>
>    But some community members in the thread (most vocally Matt Parsons,<br>
>    e.g. here<br>
>    [3]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment</a><br>
>    -2651558160 ) feel that there should be more options, that is that all<br>
>    of<br>
>       `import splice A` / `import A splice`<br>
>       `import quote B` / `import A quote`<br>
> <br>
>    Be available, lest people prefer the right-hand positions and do a<br>
>    proposal to add an extra extension later.<br>
> <br>
>    The authors are ok (but evidently not ecstatic<br>
>    [4]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment</a><br>
>    -2671436455 ) with allowing both positions for their keyword. It turns<br>
>    out not to be too big of a hassle to implement. Which I propose to be<br>
>    the resolution. Very non-committal on our part, but because it isn't<br>
>    costly, we might as well.<br>
> <br>
>    This hasn't been a very busy thread, so… let me backtrack: I'll be on<br>
>    holiday next week, so I'll accept the changes as I'm back, this means<br>
>    that you have one week to disagree. Now, this hasn't been a very busy<br>
>    thread so I expect nobody has strong opinions. But, let me propose a<br>
>    protocol. If (and only if) someone is of the strong opinion that only<br>
>    in front is a much better solution. Let them state “I strongly think<br>
>    that `import splice A` should be the only syntax`. One of us says that,<br>
>    let each of you vote, I'll tally the vote when I'm back.<br>
> <br>
>    PS: I'm excluding only `import A splice` as an option because the<br>
>    authors don't want that and it would require an overwhelming majority<br>
>    to force that on the authors, which evidently doesn't exist, so let's<br>
>    not muddy the water. So the two options are “only in front” and “both<br>
>    position”<br>
> <br>
>    Speak to you all in a week,<br>
>    Arnaud<br>
> <br>
>    On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack<br>
>    <[5]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
> <br>
>    There's a little bit of a debate going on in the Github thread on the<br>
>    topic of syntax. I'll give this one one last push. If the authors<br>
>    decide that they are ok with specifying the keywords before and after<br>
>    the module name, then we can accept immediately, as there's no voice<br>
>    against this. Otherwise I'll recapitulate everybody's argument here and<br>
>    call for a quick vote.<br>
> <br>
>    On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack<br>
>    <[6]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
> <br>
>    For the record, the syntactic alternatives can be found in [§8.5<br>
>    Syntactic<br>
>    alternatives]([7]<a href="https://github.com/well-typed/ghc-proposals/blob/wip/l" rel="noreferrer" target="_blank">https://github.com/well-typed/ghc-proposals/blob/wip/l</a><br>
>    evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati<br>
>    ves)<br>
> <br>
>    Malte seems to be uncomfortable with the fact that the proposed syntax<br>
>    is<br>
> <br>
>    import slice Foo<br>
>    import quote Bar<br>
> <br>
>    Even when ImportQualifiedPost, which enables the syntax<br>
> <br>
>    import Foo qualified [as …]<br>
> <br>
>    is enabled.<br>
> <br>
>    The proposal offers alternative syntaxes like<br>
> <br>
>    import Foo slice<br>
>    Import Bar quote<br>
> <br>
>    or (to sound more English)<br>
> <br>
>    import Foo for slice<br>
>    import Bar for quote<br>
> <br>
>    Richard Eisenberg, in the thread, suggests that the motivation for<br>
>    ImportQualifiedPost doesn't apply to slice/quote because he believes<br>
>    that there's going to be one block of import slice, one block of import<br>
>    (nothing), one block of import quote, and they aren't going to be mixed<br>
>    together. Them being more visually distinguished by starting with the<br>
>    keyword is an asset in this view. Many seem convinced<br>
> <br>
>    My understanding of Malte's point is that this is not intuitive enough<br>
>    that it can be left implicit in the proposal, and he'd like the<br>
>    proposal to at least state explicitly that it ignores<br>
>    ImportQualifiedPost.<br>
> <br>
>    Malte, let me know if I misrepresent your point of view (or anybody<br>
>    else's).<br>
> <br>
>    On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones<br>
>    <[8]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> <br>
>      I don’t think we were finished<br>
>      with bikeshedding the syntax. At least I think the proposal should<br>
>      state what<br>
>      the syntax is when ImportQualifiedPost is enabled and voiced that on<br>
>      the GitHub<br>
>      thread.<br>
> <br>
>    OK -- but I suspect that most of us have lost context.<br>
> <br>
>    Would you like to post (on the Github) a message explaining:<br>
>      * what the syntactic alternatives are<br>
>      * what you recommend<br>
> <br>
>    That will help to focus the discussion<br>
> <br>
>    Thanks!<br>
> <br>
>    Simon<br>
> <br>
>    On Fri, 7 Feb 2025 at 12:16, Malte Ott <[9]<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>><br>
>    wrote:<br>
> <br>
>      I do not object to accepting the proposal, but I don’t think we were<br>
>      finished<br>
>      with bikeshedding the syntax. At least I think the proposal should<br>
>      state what<br>
>      the syntax is when ImportQualifiedPost is enabled and voiced that on<br>
>      the GitHub<br>
>      thread.<br>
> <br>
>      I know we all dread wasting our time with syntax discussions but<br>
>      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<br>
>      voted 1<br>
>      >    extension this would come at a rough draw. It can't be a strong<br>
>      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<br>
>      very<br>
>      >    loudly. Otherwise I'll declare the proposal as accepted in its<br>
>      current<br>
>      >    state.<br>
>      ><br>
>      >    Best,<br>
>      >    Arnaud<br>
>      ><br>
>      >    On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo<br>
>      >    <[1][10]<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<br>
>      am<br>
>      >      still unsure<br>
>      >      > of. For the LANGUAGE pragma's is there any utility in using<br>
>      one<br>
>      >      separately<br>
>      >      > form the other? It seems there isn't. In any one file you<br>
>      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,<br>
>      let's<br>
>      >      vote. Let me<br>
>      >      > > repost a link to Simon's pro and cons post<br>
>      >      > ><br>
>      ><br>
>      [2][11]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issue" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issue</a><br>
>      comm<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<br>
>      count<br>
>      >      it as a vote<br>
>      >      > > anyway)<br>
>      >      > ><br>
>      >      > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you<br>
>      think?<br>
>      >      > ><br>
>      >      > > ---<br>
>      >      > ><br>
>      >      > > Beyond that we have a single piece of community feedback<br>
>      on the<br>
>      >      Github<br>
>      >      > > thread. It's from Michael Peyton Jones who is in favour<br>
>      of 2<br>
>      >      extensions,<br>
>      >      > > find it here<br>
>      >      > ><br>
>      ><br>
>      [3][12]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issue" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issue</a><br>
>      comm<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<br>
>      the<br>
>      >      GHC20XX (the<br>
>      >      > > last one was very modest, I'm in favour, by the way, of<br>
>      doing a<br>
>      >      much more<br>
>      >      > > ambitious language edition soon, otherwise my distaste<br>
>      will come<br>
>      >      back with<br>
>      >      > > a vengeance)<br>
>      >      > > - While I consider every proposal with several extensions<br>
>      in it<br>
>      >      with<br>
>      >      > > suspicion, the authors did argue for their second<br>
>      extension, I<br>
>      >      found the<br>
>      >      > > argument mildly convincing, and thought it wasn't worth<br>
>      fighting<br>
>      >      against.<br>
>      >      > ><br>
>      >      > > Now, even like this my preference is mildly for one<br>
>      extension.<br>
>      >      Adam says<br>
>      >      > > that it's easier to implement warnings with both the new<br>
>      syntax<br>
>      >      on and<br>
>      >      > > implicit stage persistence left turned on, than to<br>
>      implement<br>
>      >      errors when<br>
>      >      > > implicit stage persistence is turned off. It may be so,<br>
>      but I<br>
>      >      don't think<br>
>      >      > > we can avoid implementing the errors anyway, so I don't<br>
>      feel<br>
>      >      that it's a<br>
>      >      > > particularly compelling argument. I don't feel strongly.<br>
>      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][13]<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<br>
>      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][14]<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<br>
>      vote for<br>
>      >      two<br>
>      >      > > >> extensions. As I commented on the GitHub thread:<br>
>      >      > > >><br>
>      >      > > >>  > We shouldn't unnecessarily conflate a syntactic<br>
>      extension<br>
>      >      > > >> (ExplicitLevelImports) with a semantic one<br>
>      >      (NoImplicitStagePersistence)<br>
>      >      > > >> just because the common case is to want both and we<br>
>      want to<br>
>      >      keep the<br>
>      >      > > >> number of extensions lower.<br>
>      >      > > >><br>
>      >      > > >> If there are reasons why having two extensions is<br>
>      actually<br>
>      >      problematic,<br>
>      >      > > >> I'd like to hear them.<br>
>      >      > > >><br>
>      >      > > >> Also, at the risk of opening another avenue of<br>
>      discussion, we<br>
>      >      also need<br>
>      >      > > >> to resolve the syntax question (see<br>
>      >      > > >><br>
>      >      > > >><br>
>      ><br>
>      [6][15]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#discu" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#discu</a><br>
>      ssio<br>
>      >      n_r1849123243).<br>
>      >      > > >><br>
>      >      > > >> I don't have a very strong opinion here, but given<br>
>      that some<br>
>      >      people do,<br>
>      >      > > >> perhaps we should make ImportQualifiedPost affect<br>
>      splice<br>
>      >      imports so we<br>
>      >      > > >> have<br>
>      >      > > >><br>
>      >      > > >> import splice qualified A  -- By default<br>
>      >      > > >> import A splice qualified  -- Under<br>
>      ImportQualifiedPost<br>
>      >      > > >><br>
>      >      > > >> In any case, please do vote! It would be good to get<br>
>      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,<br>
>      the<br>
>      >      proposal is much<br>
>      >      > > >> > improved. See here<br>
>      >      > > >> ><br>
>      ><br>
>      <[7][16]<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<br>
>      had a<br>
>      >      large rewrite.<br>
>      >      > > >> ><br>
>      >      > > >> >   I vote to accept.<br>
>      >      > > >> ><br>
>      >      > > >> > BUT there is one point that the committee must<br>
>      resolve:<br>
>      >      *one extension<br>
>      >      > > >> > of two?*  It's just a judgement call and I lay out<br>
>      the<br>
>      >      choices in this<br>
>      >      > > >> > post<br>
>      >      > > >> > <<br>
>      >      > > >><br>
>      ><br>
>      [8][17]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issue" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issue</a><br>
>      comm<br>
>      >      ent-2609199731>.<br>
>      >      > > >> I doubt that we'll get much community feedback.  I<br>
>      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.<br>
>      Matthew is<br>
>      >      busy<br>
>      >      > > >> > implementing it for a customer and it has been on<br>
>      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][18]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >      <mailto:[10][19]<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<br>
>      notes here<br>
>      >      > > >> >     <<br>
>      >      > > >><br>
>      ><br>
>      [11][20]<a href="https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ</a><br>
>      R58R<br>
>      >      Phk5MslruY7yXD0/edit?usp=sharing<br>
>      >      > > >> >.<br>
>      >      > > >> ><br>
>      >      > > >> >     He's going to work on a revision to the proposal<br>
>      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][21]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >      <mailto:[13][22]<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<br>
>      Matthew and<br>
>      >      decide how to<br>
>      >      > > >> >         act then.<br>
>      >      > > >> ><br>
>      >      > > >> >         On Tue, 21 Jan 2025 at 02:43, Simon Peyton<br>
>      Jones<br>
>      >      > > >> >         <[14][23]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >      > > >> ><br>
>      <mailto:[15][24]<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<br>
>      on the<br>
>      >      Github thread<br>
>      >      > > >> >             <<br>
>      >      > > >><br>
>      ><br>
>      [16][25]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#pull" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#pull</a><br>
>      requ<br>
>      >      estreview-2562175116<br>
>      >      > > >> >.<br>
>      >      > > >> ><br>
>      >      > > >> >             TL:DR: I like the direction of travel<br>
>      but have<br>
>      >      too many<br>
>      >      > > >> >             questions of detail to be ready to<br>
>      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<br>
>      Spiwack<br>
>      >      > > >> >             <[17][26]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >      <mailto:[18][27]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>>><br>
>      >      > > >> >             wrote:<br>
>      >      > > >> ><br>
>      >      > > >> ><br>
>      >      > > >> >                 Mathew Pickering, Rodrigo Mesquita,<br>
>      and our<br>
>      >      own Adam<br>
>      >      > > >> >                 Gundry put forward a new proposal<br>
>      for the<br>
>      >      perenial<br>
>      >      > > >> >                 problem of dependencies and Template<br>
>      >      Haskell<br>
>      >      > > >> ><br>
>      ><br>
>      [19][28]<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>
>      >      > > >><br>
>      [20][29]<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,<br>
>      but it<br>
>      >      learns a<br>
>      >      > > >> >                 lesson from previous attempts at the<br>
>      same<br>
>      >      problem by<br>
>      >      > > >> >                 solving the absolute minimal<br>
>      problem, but<br>
>      >      this leads to<br>
>      >      > > >> >                 a somewhat fork-like situation for<br>
>      which it<br>
>      >      isn't clear<br>
>      >      > > >> >                 whether it will be resolved in the<br>
>      future.<br>
>      >      That being<br>
>      >      > > >> >                 said, it solves a real problem which<br>
>      has<br>
>      >      plagued GHC<br>
>      >      > > >> >                 compilation forever. And I'm<br>
>      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<br>
>      file,<br>
>      >      all the<br>
>      >      > > >> >                 dependencies' compiled code must<br>
>      suddenly<br>
>      >      be available<br>
>      >      > > >> >                 for typechecking. This breaks<br>
>      `-fno-code`<br>
>      >      and wounds<br>
>      >      > > >> >                 recompilation avoidance. This is<br>
>      probably<br>
>      >      the main<br>
>      >      > > >> >                 reason why it's a widely held belief<br>
>      that<br>
>      >      Template<br>
>      >      > > >> >                 Haskell is slow: you use Template<br>
>      Haskell<br>
>      >      in a few<br>
>      >      > > >> >                 modules, and suddenly your IDE is<br>
>      much less<br>
>      >      responsive<br>
>      >      > > >> >                 and you recompile more files. Yay?<br>
>      >      > > >> ><br>
>      >      > > >> >                 Anyway, the general gist of the<br>
>      solution is<br>
>      >      clear: we<br>
>      >      > > >> >                 must be able to specify that we<br>
>      don't want<br>
>      >      to import a<br>
>      >      > > >> >                 module for Template Haskell (there<br>
>      is<br>
>      >      subtleties in this<br>
>      >      > > >> >                 too as you will want a little more<br>
>      control<br>
>      >      than that for<br>
>      >      > > >> >                 cross-compilation reasons which I'm<br>
>      not<br>
>      >      competent about<br>
>      >      > > >> >                 to comment on). But the devil is in<br>
>      the<br>
>      >      many details.<br>
>      >      > > >> >                 There's this thing called implicit<br>
>      >      cross-stage<br>
>      >      > > >> >                 persistence which says that anything<br>
>      you<br>
>      >      import<br>
>      >      > > >> >                 not-for-template-haskell is going to<br>
>      be<br>
>      >      available in<br>
>      >      > > >> >                 quotes and splices anyway. Sigh… So<br>
>      you<br>
>      >      have to turn<br>
>      >      > > >> >                 this off. This is what the proposal<br>
>      does.<br>
>      >      And pretty<br>
>      >      > > >> >                 much only.<br>
>      >      > > >> ><br>
>      >      > > >> >                 They introduce a new<br>
>      >      > > >> ><br>
>      extension-XNoImplicitStagePersistence which<br>
>      >      disables<br>
>      >      > > >> >                 that, and a little bit of syntax to<br>
>      specify<br>
>      >      the stage of<br>
>      >      > > >> >                 imports. That's it.<br>
>      >      > > >> ><br>
>      >      > > >> >                 But it comes with severe<br>
>      limitations, most<br>
>      >      importantly:<br>
>      >      > > >> >                 you can't ever use a symbol defined<br>
>      in the<br>
>      >      current<br>
>      >      > > >> >                 module in a quote or splice of this<br>
>      current<br>
>      >      module,<br>
>      >      > > >> >                 typed template Haskell is turned<br>
>      off.<br>
>      >      > > >> ><br>
>      >      > > >> >                 For these situations, the proposal<br>
>      kind of<br>
>      >      advertises<br>
>      >      > > >> >                 using `-XImplicitStagePersistence`.<br>
>      Which<br>
>      >      does seem like<br>
>      >      > > >> >                 a fork-like situation to me. Not<br>
>      cool. Yet…<br>
>      >      yet Template<br>
>      >      > > >> >                 Haskell is a big messy ball of yarn,<br>
>      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<br>
>      attempts<br>
>      >      seem to support<br>
>      >      > > >> >                 this case. And I believe the authors<br>
>      are<br>
>      >      correct when<br>
>      >      > > >> >                 they claim that this proposal, in<br>
>      practice,<br>
>      >      covers a<br>
>      >      > > >> >                 vast majority of the uses of<br>
>      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<br>
>      about<br>
>      >      it, but it's<br>
>      >      > > >> >                 probably the most reasonable way<br>
>      forward.<br>
>      >      > > >> ><br>
>      >      > > >> >                 The real problem with this sort of<br>
>      proposal<br>
>      >      is that then<br>
>      >      > > >> >                 I get to write way too long an email<br>
>      to the<br>
>      >      committee.<br>
>      >      > > >> >                 Hopefully this didn't deter you.<br>
>      Read the<br>
>      >      proposal, and<br>
>      >      > > >> >                 let's vote.<br>
>      >      > > >> ><br>
>      >      > > >> >                 --<br>
>      >      > > >> >                 Arnaud Spiwack<br>
>      >      > > >> >                 Director, Research at<br>
>      >      [21][30]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a><br>
>      >      > > >> >                 <[22][31]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a>><br>
>      and<br>
>      >      [23][32]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a><br>
>      >      > > >> >                 <[24][33]<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][34]<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][35]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      >      > > >><br>
>      ><br>
>      [27][36]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri</a><br>
>      ng-c<br>
>      >      ommittee<br>
>      >      > > >><br>
>      >      > > > _______________________________________________<br>
>      >      > > > ghc-steering-committee mailing list<br>
>      >      > > > [28][37]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      >      > > ><br>
>      ><br>
>      [29][38]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri</a><br>
>      ng-c<br>
>      >      ommittee<br>
>      >      > > ><br>
>      >      > ><br>
>      >      > ><br>
>      >      > > --<br>
>      >      > > Arnaud Spiwack<br>
>      >      > > Director, Research at [30][39]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>      >      [31][40]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
>      >      ><br>
>      >      ><br>
>      >      > --<br>
>      >      ><br>
>      ><br>
>      --------------------------------------------------------------------<br>
>      >      --<br>
>      >      > Erik de Castro Lopo<br>
>      >      > [32][41]<a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>      >      ><br>
>      ><br>
>      >      --<br>
>      ><br>
>      --------------------------------------------------------------------<br>
>      >      --<br>
>      >      Erik de Castro Lopo<br>
>      >      [33][42]<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][43]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      ><br>
>      [35][44]<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri</a><br>
>      ng-c<br>
>      >      ommittee<br>
>      ><br>
>      >    --<br>
>      ><br>
>      >    Arnaud Spiwack<br>
>      >    Director, Research at [36][45]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>      >    [37][46]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
>      ><br>
>      > References<br>
>      ><br>
>      >    1. mailto:[47]<a href="mailto:erikd@mega-nerd.com" target="_blank">erikd@mega-nerd.com</a><br>
>      >    2.<br>
>      [48]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom</a><br>
>      ment-2609199731<br>
>      >    3.<br>
>      [49]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom</a><br>
>      ment-2609583126<br>
>      >    4. mailto:[50]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >    5. mailto:[51]<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
>      >    6.<br>
>      [52]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi</a><br>
>      on_r1849123243<br>
>      >    7. [53]<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.<br>
>      [54]<a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom</a><br>
>      ment-2609199731<br>
>      >    9. mailto:[55]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >   10. mailto:[56]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >   11.<br>
>      [57]<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>
>      >   12. mailto:[58]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >   13. mailto:[59]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >   14. mailto:[60]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >   15. mailto:[61]<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>      >   16.<br>
>      [62]<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>
>      >   17. mailto:[63]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >   18. mailto:[64]<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>      >   19. [65]<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. [66]<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. [67]<a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>      >   22. [68]<a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>      >   23. [69]<a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>      >   24. [70]<a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>      >   25. [71]<a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
>      >   26. mailto:[72]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      >   27.<br>
>      [73]<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>
>      >   28. mailto:[74]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      >   29.<br>
>      [75]<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>
>      >   30. [76]<a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>      >   31. [77]<a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>      >   32. [78]<a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>      >   33. [79]<a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>      >   34. mailto:[80]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      >   35.<br>
>      [81]<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>
>      >   36. [82]<a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>      >   37. [83]<a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
> <br>
>      > _______________________________________________<br>
>      > ghc-steering-committee mailing list<br>
>      > [84]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      ><br>
>      [85]<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>
>      [86]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      [87]<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>
>      [88]<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>      [89]<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>
>    Arnaud Spiwack<br>
>    Director, Research at [90]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>    [91]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> <br>
>      --<br>
> <br>
>    Arnaud Spiwack<br>
>    Director, Research at [92]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>    [93]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> <br>
>      --<br>
> <br>
>    Arnaud Spiwack<br>
>    Director, Research at [94]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>    [95]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> <br>
>    --<br>
>    Arnaud Spiwack<br>
>    Director, Research at [96]<a href="https://moduscreate.com" rel="noreferrer" target="_blank">https://moduscreate.com</a> and<br>
>    [97]<a href="https://tweag.io" rel="noreferrer" target="_blank">https://tweag.io</a>.<br>
> <br>
> References<br>
> <br>
>    1. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>    2. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>    3. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160</a><br>
>    4. <a href="https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455</a><br>
>    5. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>    6. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>    7. <a href="https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives" rel="noreferrer" target="_blank">https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives</a><br>
>    8. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>    9. mailto:<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a><br>
>   10. mailto:<a href="mailto:erikd@mega-nerd.com" target="_blank">erikd@mega-nerd.com</a><br>
>   11. <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>
>   12. <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>
>   13. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   14. mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
>   15. <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>
>   16. <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>
>   17. <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>
>   18. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   19. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   20. <a href="https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R</a><br>
>   21. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   22. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   23. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   24. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   25. <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>
>   26. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   27. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   28. <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>
>   29. <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>
>   30. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   31. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   32. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   33. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   34. <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
>   35. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   36. <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>
>   37. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   38. <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>
>   39. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   40. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   41. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>   42. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>   43. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   44. <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>
>   45. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   46. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   47. mailto:<a href="mailto:erikd@mega-nerd.com" target="_blank">erikd@mega-nerd.com</a><br>
>   48. <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>
>   49. <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>
>   50. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   51. mailto:<a href="mailto:adam@well-typed.com" target="_blank">adam@well-typed.com</a><br>
>   52. <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>
>   53. <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>
>   54. <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>
>   55. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   56. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   57. <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>
>   58. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   59. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   60. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   61. mailto:<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a><br>
>   62. <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>
>   63. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   64. mailto:<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a><br>
>   65. <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>
>   66. <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>
>   67. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   68. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   69. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   70. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   71. <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
>   72. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   73. <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>
>   74. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   75. <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>
>   76. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   77. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   78. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>   79. <a href="http://www.mega-nerd.com/" rel="noreferrer" target="_blank">http://www.mega-nerd.com/</a><br>
>   80. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   81. <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>
>   82. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   83. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   84. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   85. <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>
>   86. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   87. <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>
>   88. mailto:<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>   89. <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>
>   90. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   91. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   92. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   93. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   94. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   95. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
>   96. <a href="https://moduscreate.com/" rel="noreferrer" target="_blank">https://moduscreate.com/</a><br>
>   97. <a href="https://tweag.io/" rel="noreferrer" target="_blank">https://tweag.io/</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>