[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Simon Peyton Jones
simon.peytonjones at gmail.com
Fri Feb 7 16:18:49 UTC 2025
I don’t think we were finished
with bikeshedding the syntax. At least I think the proposal should state
what
the syntax is when ImportQualifiedPost is enabled and voiced that on the
GitHub
thread.
OK -- but I suspect that most of us have lost context.
Would you like to post (on the Github) a message explaining:
- what the syntactic alternatives are
- what you recommend
That will help to focus the discussion
Thanks!
Simon
On Fri, 7 Feb 2025 at 12:16, Malte Ott <malte.ott at maralorn.de> wrote:
> I do not object to accepting the proposal, but I don’t think we were
> finished
> with bikeshedding the syntax. At least I think the proposal should state
> what
> the syntax is when ImportQualifiedPost is enabled and voiced that on the
> GitHub
> thread.
>
> I know we all dread wasting our time with syntax discussions but lets at
> least
> think about it for 5 minutes.
>
> Best,
> Malte
>
> On 2025-02-07 15:48, Arnaud Spiwack wrote:
> > Ok, we have enough of a quorum at this point. If everybody else voted
> 1
> > extension this would come at a rough draw. It can't be a strong enough
> > push to overrule the preference of the authors.
> >
> > I'll give it a handful more day, say until next Wednesday 12th
> > February. If someone has a strong objection, please voice it very
> > loudly. Otherwise I'll declare the proposal as accepted in its current
> > state.
> >
> > Best,
> > Arnaud
> >
> > On Fri, 7 Feb 2025 at 08:01, Erik de Castro Lopo
> > <[1]erikd at mega-nerd.com> wrote:
> >
> > OK, slightly in favor of two extensions.
> >
> > Erik
> >
> > Erik de Castro Lopo wrote:
> >
> > > Hi,
> > >
> > > I have read through the proposal, but there is something I am
> > still unsure
> > > of. For the LANGUAGE pragma's is there any utility in using one
> > separately
> > > form the other? It seems there isn't. In any one file you would
> > use either
> > > one or the other.
> > >
> > > Thanks,
> > > Erik
> > >
> > > Arnaud Spiwack wrote:
> > >
> > > > Sorry I disappeared for a while. I second Simon's call, let's
> > vote. Let me
> > > > repost a link to Simon's pro and cons post
> > > >
> > [2]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > ent-2609199731
> > > >
> > > > So far, we have the following votes
> > > >
> > > > - Simon: 1 extension
> > > > - Adam: 2 extension (feels quite strongly about it)
> > > > - Sebastian: 1 extension (on the Github thread, but I'll count
> > it as a vote
> > > > anyway)
> > > >
> > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you think?
> > > >
> > > > ---
> > > >
> > > > Beyond that we have a single piece of community feedback on the
> > Github
> > > > thread. It's from Michael Peyton Jones who is in favour of 2
> > extensions,
> > > > find it here
> > > >
> > [3]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > ent-2609583126
> > > >
> > > > ---
> > > >
> > > > For the record, I hadn't commented about it in my
> > recommendation, despite
> > > > my well-known and desperately public distaste for micro
> > extensions. I have
> > > > a couple of reasons:
> > > > - I dislike micro-extensions less now that we are doing the
> > GHC20XX (the
> > > > last one was very modest, I'm in favour, by the way, of doing a
> > much more
> > > > ambitious language edition soon, otherwise my distaste will come
> > back with
> > > > a vengeance)
> > > > - While I consider every proposal with several extensions in it
> > with
> > > > suspicion, the authors did argue for their second extension, I
> > found the
> > > > argument mildly convincing, and thought it wasn't worth fighting
> > against.
> > > >
> > > > Now, even like this my preference is mildly for one extension.
> > Adam says
> > > > that it's easier to implement warnings with both the new syntax
> > on and
> > > > implicit stage persistence left turned on, than to implement
> > errors when
> > > > implicit stage persistence is turned off. It may be so, but I
> > don't think
> > > > we can avoid implementing the errors anyway, so I don't feel
> > that it's a
> > > > particularly compelling argument. I don't feel strongly. But
> > that's
> > > > presumably where my vote goes.
> > > >
> > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones
> > <[4]simon.peytonjones at gmail.com>
> > > > wrote:
> > > >
> > > > > 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
> > <[5]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
> > > > >>
> > > > >>
> > [6]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio
> > n_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
> > > > >> >
> > <[7]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
> > > > >> > <
> > > > >>
> > [8]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > ent-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
> > > > >> > <[9]simon.peytonjones at gmail.com
> > <mailto:[10]simon.peytonjones at gmail.com>>
> > > > >> wrote:
> > > > >> >
> > > > >> > Matthew and I had a good conversation. Some notes here
> > > > >> > <
> > > > >>
> > [11]
> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
> > Phk5MslruY7yXD0/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
> > > > >> > <[12]arnaud.spiwack at tweag.io
> > <mailto:[13]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
> > > > >> > <[14]simon.peytonjones at gmail.com
> > > > >> > <mailto:[15]simon.peytonjones at gmail.com>> wrote:
> > > > >> >
> > > > >> > Arnaud
> > > > >> >
> > > > >> > I have responded with a lot of feedback on the
> > Github thread
> > > > >> > <
> > > > >>
> > [16]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
> > estreview-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
> > > > >> > <[17]arnaud.spiwack at tweag.io
> > <mailto:[18]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
> > > > >> >
> > [19]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > > >> > <
> > > > >> [20]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
> > [21]https://moduscreate.com
> > > > >> > <[22]https://moduscreate.com> and
> > [23]https://tweag.io
> > > > >> > <[24]https://tweag.io>.
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Adam Gundry, Haskell Consultant
> > > > >> Well-Typed LLP, [25]https://www.well-typed.com/
> > > > >>
> > > > >> Registered in England & Wales, OC335890
> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England
> > > > >>
> > > > >> _______________________________________________
> > > > >> ghc-steering-committee mailing list
> > > > >> [26]ghc-steering-committee at haskell.org
> > > > >>
> > [27]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > > >>
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > [28]ghc-steering-committee at haskell.org
> > > > >
> > [29]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > > >
> > > >
> > > >
> > > > --
> > > > Arnaud Spiwack
> > > > Director, Research at [30]https://moduscreate.com and
> > [31]https://tweag.io.
> > >
> > >
> > > --
> > >
> > --------------------------------------------------------------------
> > --
> > > Erik de Castro Lopo
> > > [32]http://www.mega-nerd.com/
> > >
> >
> > --
> > --------------------------------------------------------------------
> > --
> > Erik de Castro Lopo
> > [33]http://www.mega-nerd.com/
> > _______________________________________________
> > ghc-steering-committee mailing list
> > [34]ghc-steering-committee at haskell.org
> > [35]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> >
> > --
> >
> > Arnaud Spiwack
> > Director, Research at [36]https://moduscreate.com and
> > [37]https://tweag.io.
> >
> > References
> >
> > 1. mailto:erikd at mega-nerd.com
> > 2.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> > 3.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126
> > 4. mailto:simon.peytonjones at gmail.com
> > 5. mailto:adam at well-typed.com
> > 6.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243
> > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 8.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> > 9. mailto:simon.peytonjones at gmail.com
> > 10. mailto:simon.peytonjones at gmail.com
> > 11.
> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing
> > 12. mailto:arnaud.spiwack at tweag.io
> > 13. mailto:arnaud.spiwack at tweag.io
> > 14. mailto:simon.peytonjones at gmail.com
> > 15. mailto:simon.peytonjones at gmail.com
> > 16.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116
> > 17. mailto:arnaud.spiwack at tweag.io
> > 18. mailto:arnaud.spiwack at tweag.io
> > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 21. https://moduscreate.com/
> > 22. https://moduscreate.com/
> > 23. https://tweag.io/
> > 24. https://tweag.io/
> > 25. https://www.well-typed.com/
> > 26. mailto:ghc-steering-committee at haskell.org
> > 27.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 28. mailto:ghc-steering-committee at haskell.org
> > 29.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 30. https://moduscreate.com/
> > 31. https://tweag.io/
> > 32. http://www.mega-nerd.com/
> > 33. http://www.mega-nerd.com/
> > 34. mailto:ghc-steering-committee at haskell.org
> > 35.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 36. https://moduscreate.com/
> > 37. 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
>
> _______________________________________________
> 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/20250207/91603ce1/attachment-0001.html>
More information about the ghc-steering-committee
mailing list