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

[Simon Marlow]

Seems reasonable and the impact seems minimal in practice (I like the
pandoc example). In fact in our Buck2 build system at Meta we already have
a similar distinction between compile-time and runtime dependencies but it
doesn't have the corresponding language support, so getting the build
system settings wrong can lead to weird compile errors - well, compile-time
link errors typically.

+1

Simon

On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack <arnaud.spiwack at tweag.io> 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
>
> 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 and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250120/9c35c8cf/attachment.html>