[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept

[Adam Gundry]

I've just discovered that there were a bunch of messages to the mailing 
list regarding this proposal that were somehow not delivered to me. So 
apologies for my apparent silence on the syntax question!

Regardless, I've marked this proposal as accepted at Arnaud's request 
(https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2703780627).

Cheers,

Adam



On 09/01/2025 06:31, Arnaud Spiwack wrote:
> 
> Mathew Pickering, Rodrigo Mesquita, and our own Adam Gundry put forward 
> a new proposal for the perenial problem of dependencies and Template 
> Haskell https://github.com/ghc-proposals/ghc-proposals/pull/682 
> <https://github.com/ghc-proposals/ghc-proposals/pull/682>
> 
> I've got to be honest, I'm not fully convinced by the proposal. More on 
> that in a minute, but it learns a lesson from previous attempts at the 
> same problem by solving the absolute minimal problem, but this leads to 
> a somewhat fork-like situation for which it isn't clear whether it will 
> be resolved in the future. That being said, it solves a real problem 
> which has plagued GHC compilation forever. And I'm inclined to believe 
> that we can't really do much better.
> 
> But I'm getting ahead of myself. The problem is that when you have 
> -XTemplateHaskell in a file, all the dependencies' compiled code must 
> suddenly be available for typechecking. This breaks `-fno-code` and 
> wounds recompilation avoidance. This is probably the main reason why 
> it's a widely held belief that Template Haskell is slow: you use 
> Template Haskell in a few modules, and suddenly your IDE is much less 
> responsive and you recompile more files. Yay?
> 
> Anyway, the general gist of the solution is clear: we must be able to 
> specify that we don't want to import a module for Template Haskell 
> (there is subtleties in this too as you will want a little more control 
> than that for cross-compilation reasons which I'm not competent about to 
> comment on). But the devil is in the many details. There's this thing 
> called implicit cross-stage persistence which says that anything you 
> import not-for-template-haskell is going to be available in quotes and 
> splices anyway. Sigh… So you have to turn this off. This is what the 
> proposal does. And pretty much only.
> 
> They introduce a new extension-XNoImplicitStagePersistence which 
> disables that, and a little bit of syntax to specify the stage of 
> imports. That's it.
> 
> But it comes with severe limitations, most importantly: you can't ever 
> use a symbol defined in the current module in a quote or splice of this 
> current module, typed template Haskell is turned off.
> 
> For these situations, the proposal kind of advertises using 
> `-XImplicitStagePersistence`. Which does seem like a fork-like situation 
> to me. Not cool. Yet… yet Template Haskell is a big messy ball of yarn, 
> and I don't think it's fair to ask of any proposal to entangle it 
> completely. The failure of past attempts seem to support this case. And 
> I believe the authors are correct when they claim that this proposal, in 
> practice, covers a vast majority of the uses of Template Haskell out 
> there. So maybe we can see that as a new foundation for Template 
> Haskell. I'm not thrilled about it, but it's probably the most 
> reasonable way forward.
> 
> The real problem with this sort of proposal is that then I get to write 
> way too long an email to the committee. Hopefully this didn't deter you. 
> Read the proposal, and let's vote.
> 
> -- 
> Arnaud Spiwack
> Director, Research at https://moduscreate.com <https://moduscreate.com> 
> and https://tweag.io <https://tweag.io>.

-- 
Adam Gundry, Haskell Consultant
Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890
27 Old Gloucester Street, London WC1N 3AX, England