[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Arnaud Spiwack
arnaud.spiwack at tweag.io
Thu Feb 6 07:26:17 UTC 2025
Simon M: I'm pretty we would enable either both or neither in editions, yes.
---
Erik: See the argument summarized by Simon PJ here
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 <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 <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
>> >
>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-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
>> >
>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-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 <
>> 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 <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
>> > >>
>> > > _______________________________________________
>> > > 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.
>>
>>
>> --
>> ----------------------------------------------------------------------
>> Erik de Castro Lopo
>> http://www.mega-nerd.com/
>> _______________________________________________
>> 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/20250206/1966172a/attachment-0001.html>
More information about the ghc-steering-committee
mailing list