[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