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