[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Matthías Páll Gissurarson
mpg at mpg.is
Thu Feb 6 16:57:22 UTC 2025
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 <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
> 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.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
--
-- Matthías Páll Gissurarson <http://mpg.is/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20250206/6c7805cc/attachment-0001.html>
More information about the ghc-steering-committee
mailing list