<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Yes: all members of the steering committee, please vote. Evaluating proposals is what we all signed up to do!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Thanks</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 3 Feb 2025 at 20:45, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.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">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>
<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>
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 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 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>
> <<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>>. I doubt that we'll get much community feedback. I suggest that we just 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>>> wrote:<br>
> <br>
> Matthew and I had a good conversation. Some notes here<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>
> 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>
> <<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>
> 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>
> <<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>
</blockquote></div>