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

[Simon Peyton Jones]

Matthew and I had a good conversation. Some notes here
<https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing>.


He's going to work on a revision to the proposal which I'll iterate with
him.

Simon

On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> 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/bb239247/attachment.html>