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

[Arnaud Spiwack]

Then, let's wait until your call with Matthew and decide how to act then.

On Tue, 21 Jan 2025 at 02:43, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Arnaud
>
> I have responded with a lot of feedback on the Github thread
> <https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116>
> .
>
> TL:DR: I like the direction of travel but have too many questions of
> detail to be ready to accept it just yet.
>
> I have arranged a call with Matthew.
>
> 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
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250121/d47da3cd/attachment-0001.html>