<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>