[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Adam Gundry
adam at well-typed.com
Mon Feb 3 20:45:10 UTC 2025
I'm (unsurprisingly) in favour of acceptance, and I vote for two
extensions. As I commented on the GitHub thread:
> We shouldn't unnecessarily conflate a syntactic extension
(ExplicitLevelImports) with a semantic one (NoImplicitStagePersistence)
just because the common case is to want both and we want to keep the
number of extensions lower.
If there are reasons why having two extensions is actually problematic,
I'd like to hear them.
Also, at the risk of opening another avenue of discussion, we also need
to resolve the syntax question (see
https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243).
I don't have a very strong opinion here, but given that some people do,
perhaps we should make ImportQualifiedPost affect splice imports so we have
import splice qualified A -- By default
import A splice qualified -- Under ImportQualifiedPost
In any case, please do vote! It would be good to get this proposal done.
Cheers,
Adam
On 27/01/2025 11:52, Simon Peyton Jones wrote:
> 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 <mailto: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 <mailto: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
> <mailto: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 <mailto: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
> <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
More information about the ghc-steering-committee
mailing list