<div dir="ltr"><div>I don't feel strongly about 1 vs 2 extensions, because I think the direction of travel is away from recommending individual extensions as a way to interact with the compiler and towards GHC20xx instead. And in GHC20xx I think we would enable either both or neither of these extensions, correct?</div><div><br></div><div>Cheers</div><div>Simon<br></div><br><div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, 5 Feb 2025 at 08:16, 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">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>
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></div>