[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Simon Peyton Jones
simon.peytonjones at gmail.com
Mon Feb 3 22:13:04 UTC 2025
Yes: all members of the steering committee, please vote. Evaluating
proposals is what we all signed up to do!
Thanks
Simon
On Mon, 3 Feb 2025 at 20:45, Adam Gundry <adam at well-typed.com> wrote:
> 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
>
> _______________________________________________
> 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/20250203/66188bd2/attachment-0001.html>
More information about the ghc-steering-committee
mailing list