[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Arnaud Spiwack
arnaud.spiwack at tweag.io
Thu Mar 6 12:55:50 UTC 2025
>
> My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or
> something similar and then treat splice exactly as qualified.
> Seeing that that’s much too much trouble I would consider doing that but
> not
> changing the extension name.
(aside: with ImportQualifiedPost turned, both the `qualified` keyword
before and the `qualified` keyword after are accepted).
---
Nobody seems to have an opinion. Owing to various illnesses traversing my
households (and my lungs…) this week, I let that slide a bit longer than I
wanted. But anyway. I'll interpret silence as assent, and mark the proposal
as accepted. We've waited too long already.
On Mon, 3 Mar 2025 at 19:03, Malte Ott <malte.ott at maralorn.de> wrote:
> I for my part are kinda dissatisfied by both options.
> And I am very much sympathetic to the position that a committee shouldn’t
> settle
> alternatives by allowing all of them.
> That being said I am still in favor of leaving the proposal like it is
> now, which is (B).
>
> My dream would be to rename ImportQualifiedPost to ImportAnnotationsPost or
> something similar and then treat splice exactly as qualified.
> Seeing that that’s much too much trouble I would consider doing that but
> not
> changing the extension name.
>
> I can also see the reasoning that we should just go with (A) now without
> blocking the proposal any longer because it will always be possible to
> convert
> it to (B) later.
>
> Best
> Malte
>
> On 2025-03-03 15:52, Arnaud Spiwack wrote:
> > There may have been delivery issues last week to the committee mailing
> > list. Did everybody get this email by Simon and mine below?
> >
> > On Fri, 21 Feb 2025 at 17:23, Simon Peyton Jones
> > <[1]simon.peytonjones at gmail.com> wrote:
> >
> > Syntax is always troublesome, and best resolved by a vote. I think
> you
> > are asking us to vote on:
> > * (A) splice/quote keywords only before the module name
> > * (B) splice/quote keywords either before or after the module name
> >
> > I vote (A). My opinion is not a strong one. Let's see what other
> > committee members think. RSVP
> >
> > Simon
> >
> > On Fri, 21 Feb 2025 at 07:17, Arnaud Spiwack
> > <[2]arnaud.spiwack at tweag.io> wrote:
> >
> > So, let me recap the situation.
> >
> > The authors favourite syntax is
> > `import splice A`
> > `import quote B`
> >
> > But some community members in the thread (most vocally Matt Parsons,
> > e.g. here
> > [3]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment
> > -2651558160 ) feel that there should be more options, that is that all
> > of
> > `import splice A` / `import A splice`
> > `import quote B` / `import A quote`
> >
> > Be available, lest people prefer the right-hand positions and do a
> > proposal to add an extra extension later.
> >
> > The authors are ok (but evidently not ecstatic
> > [4]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment
> > -2671436455 ) with allowing both positions for their keyword. It turns
> > out not to be too big of a hassle to implement. Which I propose to be
> > the resolution. Very non-committal on our part, but because it isn't
> > costly, we might as well.
> >
> > This hasn't been a very busy thread, so… let me backtrack: I'll be on
> > holiday next week, so I'll accept the changes as I'm back, this means
> > that you have one week to disagree. Now, this hasn't been a very busy
> > thread so I expect nobody has strong opinions. But, let me propose a
> > protocol. If (and only if) someone is of the strong opinion that only
> > in front is a much better solution. Let them state “I strongly think
> > that `import splice A` should be the only syntax`. One of us says
> that,
> > let each of you vote, I'll tally the vote when I'm back.
> >
> > PS: I'm excluding only `import A splice` as an option because the
> > authors don't want that and it would require an overwhelming majority
> > to force that on the authors, which evidently doesn't exist, so let's
> > not muddy the water. So the two options are “only in front” and “both
> > position”
> >
> > Speak to you all in a week,
> > Arnaud
> >
> > On Fri, 14 Feb 2025 at 14:19, Arnaud Spiwack
> > <[5]arnaud.spiwack at tweag.io> wrote:
> >
> > There's a little bit of a debate going on in the Github thread on the
> > topic of syntax. I'll give this one one last push. If the authors
> > decide that they are ok with specifying the keywords before and after
> > the module name, then we can accept immediately, as there's no voice
> > against this. Otherwise I'll recapitulate everybody's argument here
> and
> > call for a quick vote.
> >
> > On Mon, 10 Feb 2025 at 15:25, Arnaud Spiwack
> > <[6]arnaud.spiwack at tweag.io> wrote:
> >
> > For the record, the syntactic alternatives can be found in [§8.5
> > Syntactic
> > alternatives]([7]
> https://github.com/well-typed/ghc-proposals/blob/wip/l
> >
> evel-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternati
> > ves)
> >
> > Malte seems to be uncomfortable with the fact that the proposed syntax
> > is
> >
> > import slice Foo
> > import quote Bar
> >
> > Even when ImportQualifiedPost, which enables the syntax
> >
> > import Foo qualified [as …]
> >
> > is enabled.
> >
> > The proposal offers alternative syntaxes like
> >
> > import Foo slice
> > Import Bar quote
> >
> > or (to sound more English)
> >
> > import Foo for slice
> > import Bar for quote
> >
> > Richard Eisenberg, in the thread, suggests that the motivation for
> > ImportQualifiedPost doesn't apply to slice/quote because he believes
> > that there's going to be one block of import slice, one block of
> import
> > (nothing), one block of import quote, and they aren't going to be
> mixed
> > together. Them being more visually distinguished by starting with the
> > keyword is an asset in this view. Many seem convinced
> >
> > My understanding of Malte's point is that this is not intuitive enough
> > that it can be left implicit in the proposal, and he'd like the
> > proposal to at least state explicitly that it ignores
> > ImportQualifiedPost.
> >
> > Malte, let me know if I misrepresent your point of view (or anybody
> > else's).
> >
> > On Sat, 8 Feb 2025 at 01:19, Simon Peyton Jones
> > <[8]simon.peytonjones at gmail.com> wrote:
> >
> > 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 <[9]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][10]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][11]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issue
> > comm
> > > 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][12]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issue
> > comm
> > > 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][13]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][14]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][15]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#discu
> > ssio
> > > 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][16]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][17]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issue
> > comm
> > > 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][18]simon.peytonjones at gmail.com
> > > <mailto:[10][19]simon.peytonjones at gmail.com>>
> > > > > >> wrote:
> > > > > >> >
> > > > > >> > Matthew and I had a good conversation. Some
> > notes here
> > > > > >> > <
> > > > > >>
> > >
> > [11][20]
> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQ
> > R58R
> > > 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][21]arnaud.spiwack at tweag.io
> > > <mailto:[13][22]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][23]simon.peytonjones at gmail.com
> > > > > >> >
> > <mailto:[15][24]simon.peytonjones at gmail.com>> wrote:
> > > > > >> >
> > > > > >> > Arnaud
> > > > > >> >
> > > > > >> > I have responded with a lot of feedback
> > on the
> > > Github thread
> > > > > >> > <
> > > > > >>
> > >
> > [16][25]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#pull
> > requ
> > > 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][26]arnaud.spiwack at tweag.io
> > > <mailto:[18][27]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][28]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > > > >> > <
> > > > > >>
> > [20][29]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][30]https://moduscreate.com
> > > > > >> > <[22][31]https://moduscreate.com>
> > and
> > > [23][32]https://tweag.io
> > > > > >> > <[24][33]https://tweag.io>.
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Adam Gundry, Haskell Consultant
> > > > > >> Well-Typed LLP, [25][34]https://www.well-typed.com/
> > > > > >>
> > > > > >> Registered in England & Wales, OC335890
> > > > > >> 27 Old Gloucester Street, London WC1N 3AX, England
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> ghc-steering-committee mailing list
> > > > > >> [26][35]ghc-steering-committee at haskell.org
> > > > > >>
> > >
> > [27][36]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> > ng-c
> > > ommittee
> > > > > >>
> > > > > > _______________________________________________
> > > > > > ghc-steering-committee mailing list
> > > > > > [28][37]ghc-steering-committee at haskell.org
> > > > > >
> > >
> > [29][38]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> > ng-c
> > > ommittee
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Arnaud Spiwack
> > > > > Director, Research at [30][39]https://moduscreate.com
> and
> > > [31][40]https://tweag.io.
> > > >
> > > >
> > > > --
> > > >
> > >
> > --------------------------------------------------------------------
> > > --
> > > > Erik de Castro Lopo
> > > > [32][41]http://www.mega-nerd.com/
> > > >
> > >
> > > --
> > >
> > --------------------------------------------------------------------
> > > --
> > > Erik de Castro Lopo
> > > [33][42]http://www.mega-nerd.com/
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > [34][43]ghc-steering-committee at haskell.org
> > >
> > [35][44]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> > ng-c
> > > ommittee
> > >
> > > --
> > >
> > > Arnaud Spiwack
> > > Director, Research at [36][45]https://moduscreate.com and
> > > [37][46]https://tweag.io.
> > >
> > > References
> > >
> > > 1. mailto:[47]erikd at mega-nerd.com
> > > 2.
> > [48]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> > ment-2609199731
> > > 3.
> > [49]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> > ment-2609583126
> > > 4. mailto:[50]simon.peytonjones at gmail.com
> > > 5. mailto:[51]adam at well-typed.com
> > > 6.
> > [52]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi
> > on_r1849123243
> > > 7. [53]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > 8.
> > [54]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> > ment-2609199731
> > > 9. mailto:[55]simon.peytonjones at gmail.com
> > > 10. mailto:[56]simon.peytonjones at gmail.com
> > > 11.
> > [57]
> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
> > Phk5MslruY7yXD0/edit?usp=sharing
> > > 12. mailto:[58]arnaud.spiwack at tweag.io
> > > 13. mailto:[59]arnaud.spiwack at tweag.io
> > > 14. mailto:[60]simon.peytonjones at gmail.com
> > > 15. mailto:[61]simon.peytonjones at gmail.com
> > > 16.
> > [62]
> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
> > estreview-2562175116
> > > 17. mailto:[63]arnaud.spiwack at tweag.io
> > > 18. mailto:[64]arnaud.spiwack at tweag.io
> > > 19. [65]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > 20. [66]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > 21. [67]https://moduscreate.com/
> > > 22. [68]https://moduscreate.com/
> > > 23. [69]https://tweag.io/
> > > 24. [70]https://tweag.io/
> > > 25. [71]https://www.well-typed.com/
> > > 26. mailto:[72]ghc-steering-committee at haskell.org
> > > 27.
> > [73]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > 28. mailto:[74]ghc-steering-committee at haskell.org
> > > 29.
> > [75]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > 30. [76]https://moduscreate.com/
> > > 31. [77]https://tweag.io/
> > > 32. [78]http://www.mega-nerd.com/
> > > 33. [79]http://www.mega-nerd.com/
> > > 34. mailto:[80]ghc-steering-committee at haskell.org
> > > 35.
> > [81]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> > > 36. [82]https://moduscreate.com/
> > > 37. [83]https://tweag.io/
> >
> > > _______________________________________________
> > > ghc-steering-committee mailing list
> > > [84]ghc-steering-committee at haskell.org
> > >
> > [85]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > [86]ghc-steering-committee at haskell.org
> > [87]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> >
> > _______________________________________________
> > ghc-steering-committee mailing list
> > [88]ghc-steering-committee at haskell.org
> > [89]
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > ommittee
> >
> > --
> > Arnaud Spiwack
> > Director, Research at [90]https://moduscreate.com and
> > [91]https://tweag.io.
> >
> > --
> >
> > Arnaud Spiwack
> > Director, Research at [92]https://moduscreate.com and
> > [93]https://tweag.io.
> >
> > --
> >
> > Arnaud Spiwack
> > Director, Research at [94]https://moduscreate.com and
> > [95]https://tweag.io.
> >
> > --
> > Arnaud Spiwack
> > Director, Research at [96]https://moduscreate.com and
> > [97]https://tweag.io.
> >
> > References
> >
> > 1. mailto:simon.peytonjones at gmail.com
> > 2. mailto:arnaud.spiwack at tweag.io
> > 3.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558160
> > 4.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436455
> > 5. mailto:arnaud.spiwack at tweag.io
> > 6. mailto:arnaud.spiwack at tweag.io
> > 7.
> https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives
> > 8. mailto:simon.peytonjones at gmail.com
> > 9. mailto:malte.ott at maralorn.de
> > 10. mailto:erikd at mega-nerd.com
> > 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > 12. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > 13. mailto:simon.peytonjones at gmail.com
> > 14. mailto:adam at well-typed.com
> > 15. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio
> > 16. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 17. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> > 18. mailto:simon.peytonjones at gmail.com
> > 19. mailto:simon.peytonjones at gmail.com
> > 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
> > 21. mailto:arnaud.spiwack at tweag.io
> > 22. mailto:arnaud.spiwack at tweag.io
> > 23. mailto:simon.peytonjones at gmail.com
> > 24. mailto:simon.peytonjones at gmail.com
> > 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
> > 26. mailto:arnaud.spiwack at tweag.io
> > 27. mailto:arnaud.spiwack at tweag.io
> > 28. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 29. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 30. https://moduscreate.com/
> > 31. https://moduscreate.com/
> > 32. https://tweag.io/
> > 33. https://tweag.io/
> > 34. https://www.well-typed.com/
> > 35. mailto:ghc-steering-committee at haskell.org
> > 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > 37. mailto:ghc-steering-committee at haskell.org
> > 38. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > 39. https://moduscreate.com/
> > 40. https://tweag.io/
> > 41. http://www.mega-nerd.com/
> > 42. http://www.mega-nerd.com/
> > 43. mailto:ghc-steering-committee at haskell.org
> > 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> > 45. https://moduscreate.com/
> > 46. https://tweag.io/
> > 47. mailto:erikd at mega-nerd.com
> > 48.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> > 49.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126
> > 50. mailto:simon.peytonjones at gmail.com
> > 51. mailto:adam at well-typed.com
> > 52.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243
> > 53. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 54.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> > 55. mailto:simon.peytonjones at gmail.com
> > 56. mailto:simon.peytonjones at gmail.com
> > 57.
> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing
> > 58. mailto:arnaud.spiwack at tweag.io
> > 59. mailto:arnaud.spiwack at tweag.io
> > 60. mailto:simon.peytonjones at gmail.com
> > 61. mailto:simon.peytonjones at gmail.com
> > 62.
> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116
> > 63. mailto:arnaud.spiwack at tweag.io
> > 64. mailto:arnaud.spiwack at tweag.io
> > 65. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 66. https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 67. https://moduscreate.com/
> > 68. https://moduscreate.com/
> > 69. https://tweag.io/
> > 70. https://tweag.io/
> > 71. https://www.well-typed.com/
> > 72. mailto:ghc-steering-committee at haskell.org
> > 73.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 74. mailto:ghc-steering-committee at haskell.org
> > 75.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 76. https://moduscreate.com/
> > 77. https://tweag.io/
> > 78. http://www.mega-nerd.com/
> > 79. http://www.mega-nerd.com/
> > 80. mailto:ghc-steering-committee at haskell.org
> > 81.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 82. https://moduscreate.com/
> > 83. https://tweag.io/
> > 84. mailto:ghc-steering-committee at haskell.org
> > 85.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 86. mailto:ghc-steering-committee at haskell.org
> > 87.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 88. mailto:ghc-steering-committee at haskell.org
> > 89.
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> > 90. https://moduscreate.com/
> > 91. https://tweag.io/
> > 92. https://moduscreate.com/
> > 93. https://tweag.io/
> > 94. https://moduscreate.com/
> > 95. https://tweag.io/
> > 96. https://moduscreate.com/
> > 97. https://tweag.io/
>
--
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/20250306/56f51953/attachment-0001.html>
More information about the ghc-steering-committee
mailing list