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

[Simon Peyton Jones]

Arnaud

OK, following my call and some further iteration, the proposal is much
improved.  See here
<https://github.com/ghc-proposals/ghc-proposals/pull/682>.   Please read
the new "Proposed Change Specification" which has had a large rewrite.

 I vote to accept.

BUT there is one point that the committee must resolve: *one extension of
two?*  It's just a judgement call and I lay out the choices in this post
<https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731>.
I doubt that we'll get much community feedback.  I suggest that we just
vote.  I vote for one, not two.  As does Sebastian.

Over to you Arnaud.  Let's get this one done. Matthew is busy implementing
it for a customer and it has been on our to-do list for some time now.
(Partly my fault.)

Simon

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

> 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/20250127/1248f4de/attachment.html>