[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Malte Ott
malte.ott at maralorn.de
Thu Feb 6 19:58:37 UTC 2025
I agrre with this.
On 2025-02-06 17:57, Matthías Páll Gissurarson wrote:
> Sorry for the late reply!
>
> After reading the thread, I'm slightly in favor of having 2 extensions.
>
> While I agree that we already have too many extensions, the case for
> having two extensions is convincing. As Arnaud mentioned, extensions
> are often used in a long list in the .cabal file, and being able to
> have ExplicitLevelImports enabled during refactoring seems to be a win.
> We want to keep migration costs minimal.
>
> The subtle case of the list of extensions being order-dependent (as
> Richard mentioned) is a bit troubling, but I agree that that should be
> left to another proposal.
>
> On Thu, 6 Feb 2025 at 08:26, Arnaud Spiwack
> <[1]arnaud.spiwack at tweag.io> wrote:
>
> Simon M: I'm pretty we would enable either both or neither in editions,
> yes.
>
> ---
>
> Erik: See the argument summarized by Simon PJ here
> [2]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment
> -2609199731 , and the handful of comment below, these are the arguments
> which have been laid down so far for either side of this conversation.
> My summary of the summary is that there are two envisioned use-case for
> turning on ExplicitLevelImports while leaving ImplicitStagePersistence
> on:
>
> - Migration (this help compile a project, but progressively follow
> warnings to prepare a project for NoImplicitStagePersistence)
> - Exceptional ImplicitStagePersistence: in the current state of the
> library, it seems that you will sometimes need to use
> ImplicitStagePersistence (to define Lift function, perhaps, or in a
> module where you define a bunch of Template Haskell: not every problem
> has been solved). But because you are in a project which uses
> ExplicitLevelImport everywhere, you may want to still mark your imports
> consistently with the rest of the project, as being imports for slices,
> quotes, or neither.
>
> On Thu, 6 Feb 2025 at 00:37, Simon Marlow <[3]marlowsd at gmail.com>
> wrote:
>
> I don't feel strongly about 1 vs 2 extensions, because I think the
> direction of travel is away from recommending individual extensions as
> a way to interact with the compiler and towards GHC20xx instead. And in
> GHC20xx I think we would enable either both or neither of these
> extensions, correct?
>
> Cheers
> Simon
>
> On Wed, 5 Feb 2025 at 08:16, Erik de Castro Lopo
> <[4]erikd at mega-nerd.com> 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
> >
> [5]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
> >
> [6]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
> <[7]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
> <[8]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
> > >>
> > >>
> [9]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
> > >> >
> <[10]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
> > >> > <
> > >>
> [11]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> ment-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
> > >> > <[12]simon.peytonjones at gmail.com
> <mailto:[13]simon.peytonjones at gmail.com>>
> > >> wrote:
> > >> >
> > >> > Matthew and I had a good conversation. Some notes here
> > >> > <
> > >>
> [14]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
> > >> > <[15]arnaud.spiwack at tweag.io
> <mailto:[16]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
> > >> > <[17]simon.peytonjones at gmail.com
> > >> > <mailto:[18]simon.peytonjones at gmail.com>> wrote:
> > >> >
> > >> > Arnaud
> > >> >
> > >> > I have responded with a lot of feedback on the
> Github thread
> > >> > <
> > >>
> [19]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
> > >> > <[20]arnaud.spiwack at tweag.io
> <mailto:[21]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
> > >> >
> [22]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > >> > <
> > >> [23]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
> [24]https://moduscreate.com
> > >> > <[25]https://moduscreate.com> and
> [26]https://tweag.io
> > >> > <[27]https://tweag.io>.
> > >>
> > >>
> > >> --
> > >> Adam Gundry, Haskell Consultant
> > >> Well-Typed LLP, [28]https://www.well-typed.com/
> > >>
> > >> Registered in England & Wales, OC335890
> > >> 27 Old Gloucester Street, London WC1N 3AX, England
> > >>
> > >> _______________________________________________
> > >> ghc-steering-committee mailing list
> > >> [29]ghc-steering-committee at haskell.org
> > >>
> [30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
> > >>
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > [31]ghc-steering-committee at haskell.org
> > >
> [32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
> > >
> >
> >
> > --
> > Arnaud Spiwack
> > Director, Research at [33]https://moduscreate.com and
> [34]https://tweag.io.
>
> --
> --------------------------------------------------------------------
> --
> Erik de Castro Lopo
> [35]http://www.mega-nerd.com/
> _______________________________________________
> ghc-steering-committee mailing list
> [36]ghc-steering-committee at haskell.org
> [37]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
>
> --
>
> Arnaud Spiwack
> Director, Research at [38]https://moduscreate.com and
> [39]https://tweag.io.
>
> _______________________________________________
> ghc-steering-committee mailing list
> [40]ghc-steering-committee at haskell.org
> [41]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
>
> --
>
> -- [42]Matthías Páll Gissurarson
>
> References
>
> 1. mailto:arnaud.spiwack at tweag.io
> 2. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> 3. mailto:marlowsd at gmail.com
> 4. mailto:erikd at mega-nerd.com
> 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126
> 7. mailto:simon.peytonjones at gmail.com
> 8. mailto:adam at well-typed.com
> 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243
> 10. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> 12. mailto:simon.peytonjones at gmail.com
> 13. mailto:simon.peytonjones at gmail.com
> 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing
> 15. mailto:arnaud.spiwack at tweag.io
> 16. mailto:arnaud.spiwack at tweag.io
> 17. mailto:simon.peytonjones at gmail.com
> 18. mailto:simon.peytonjones at gmail.com
> 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116
> 20. mailto:arnaud.spiwack at tweag.io
> 21. mailto:arnaud.spiwack at tweag.io
> 22. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 23. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 24. https://moduscreate.com/
> 25. https://moduscreate.com/
> 26. https://tweag.io/
> 27. https://tweag.io/
> 28. https://www.well-typed.com/
> 29. mailto:ghc-steering-committee at haskell.org
> 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 31. mailto:ghc-steering-committee at haskell.org
> 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 33. https://moduscreate.com/
> 34. https://tweag.io/
> 35. http://www.mega-nerd.com/
> 36. mailto:ghc-steering-committee at haskell.org
> 37. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 38. https://moduscreate.com/
> 39. https://tweag.io/
> 40. mailto:ghc-steering-committee at haskell.org
> 41. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 42. http://mpg.is/
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
More information about the ghc-steering-committee
mailing list