[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Simon Peyton Jones
simon.peytonjones at gmail.com
Fri Feb 21 08:23:16 UTC 2025
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 <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
> 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
> 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 <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 <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> For the record, the syntactic alternatives can be found in [§8.5
>>> Syntactic alternatives](
>>> https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives
>>> )
>>>
>>> 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 <
>>> 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 <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]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]
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
>>>>> > ent-2609199731
>>>>> > > >
>>>>> > > > So far, we have the following votes
>>>>> > > >
>>>>> > > > - Simon: 1 extension
>>>>> > > > - Adam: 2 extension (feels quite strongly about it)
>>>>> > > > - Sebastian: 1 extension (on the Github thread, but I'll
>>>>> count
>>>>> > it as a vote
>>>>> > > > anyway)
>>>>> > > >
>>>>> > > > Eric, Moritz, Malta, Matthías, Erik, Jakob: what do you
>>>>> think?
>>>>> > > >
>>>>> > > > ---
>>>>> > > >
>>>>> > > > Beyond that we have a single piece of community feedback on
>>>>> the
>>>>> > Github
>>>>> > > > thread. It's from Michael Peyton Jones who is in favour of 2
>>>>> > extensions,
>>>>> > > > find it here
>>>>> > > >
>>>>> > [3]
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
>>>>> > ent-2609583126
>>>>> > > >
>>>>> > > > ---
>>>>> > > >
>>>>> > > > For the record, I hadn't commented about it in my
>>>>> > recommendation, despite
>>>>> > > > my well-known and desperately public distaste for micro
>>>>> > extensions. I have
>>>>> > > > a couple of reasons:
>>>>> > > > - I dislike micro-extensions less now that we are doing the
>>>>> > GHC20XX (the
>>>>> > > > last one was very modest, I'm in favour, by the way, of
>>>>> doing a
>>>>> > much more
>>>>> > > > ambitious language edition soon, otherwise my distaste will
>>>>> come
>>>>> > back with
>>>>> > > > a vengeance)
>>>>> > > > - While I consider every proposal with several extensions
>>>>> in it
>>>>> > with
>>>>> > > > suspicion, the authors did argue for their second
>>>>> extension, I
>>>>> > found the
>>>>> > > > argument mildly convincing, and thought it wasn't worth
>>>>> fighting
>>>>> > against.
>>>>> > > >
>>>>> > > > Now, even like this my preference is mildly for one
>>>>> extension.
>>>>> > Adam says
>>>>> > > > that it's easier to implement warnings with both the new
>>>>> syntax
>>>>> > on and
>>>>> > > > implicit stage persistence left turned on, than to implement
>>>>> > errors when
>>>>> > > > implicit stage persistence is turned off. It may be so, but
>>>>> I
>>>>> > don't think
>>>>> > > > we can avoid implementing the errors anyway, so I don't feel
>>>>> > that it's a
>>>>> > > > particularly compelling argument. I don't feel strongly. But
>>>>> > that's
>>>>> > > > presumably where my vote goes.
>>>>> > > >
>>>>> > > > On Tue, 4 Feb 2025 at 07:13, Simon Peyton Jones
>>>>> > <[4]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]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]
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio
>>>>> > n_r1849123243).
>>>>> > > > >>
>>>>> > > > >> I don't have a very strong opinion here, but given that
>>>>> some
>>>>> > people do,
>>>>> > > > >> perhaps we should make ImportQualifiedPost affect splice
>>>>> > imports so we
>>>>> > > > >> have
>>>>> > > > >>
>>>>> > > > >> import splice qualified A -- By default
>>>>> > > > >> import A splice qualified -- Under ImportQualifiedPost
>>>>> > > > >>
>>>>> > > > >> In any case, please do vote! It would be good to get this
>>>>> > proposal done.
>>>>> > > > >>
>>>>> > > > >> Cheers,
>>>>> > > > >>
>>>>> > > > >> Adam
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> On 27/01/2025 11:52, Simon Peyton Jones wrote:
>>>>> > > > >> > Arnaud
>>>>> > > > >> >
>>>>> > > > >> > OK, following my call and some further iteration, the
>>>>> > proposal is much
>>>>> > > > >> > improved. See here
>>>>> > > > >> >
>>>>> > <[7]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]
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
>>>>> > 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]simon.peytonjones at gmail.com
>>>>> > <mailto:[10]simon.peytonjones at gmail.com>>
>>>>> > > > >> wrote:
>>>>> > > > >> >
>>>>> > > > >> > Matthew and I had a good conversation. Some notes
>>>>> here
>>>>> > > > >> > <
>>>>> > > > >>
>>>>> > [11]
>>>>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
>>>>> > Phk5MslruY7yXD0/edit?usp=sharing
>>>>> > > > >> >.
>>>>> > > > >> >
>>>>> > > > >> > He's going to work on a revision to the proposal
>>>>> which
>>>>> > I'll iterate
>>>>> > > > >> > with him.
>>>>> > > > >> >
>>>>> > > > >> > Simon
>>>>> > > > >> >
>>>>> > > > >> > On Tue, 21 Jan 2025 at 07:37, Arnaud Spiwack
>>>>> > > > >> > <[12]arnaud.spiwack at tweag.io
>>>>> > <mailto:[13]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]simon.peytonjones at gmail.com
>>>>> > > > >> > <mailto:[15]simon.peytonjones at gmail.com>>
>>>>> wrote:
>>>>> > > > >> >
>>>>> > > > >> > Arnaud
>>>>> > > > >> >
>>>>> > > > >> > I have responded with a lot of feedback on
>>>>> the
>>>>> > Github thread
>>>>> > > > >> > <
>>>>> > > > >>
>>>>> > [16]
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
>>>>> > estreview-2562175116
>>>>> > > > >> >.
>>>>> > > > >> >
>>>>> > > > >> > TL:DR: I like the direction of travel but
>>>>> have
>>>>> > too many
>>>>> > > > >> > questions of detail to be ready to accept
>>>>> it
>>>>> > just yet.
>>>>> > > > >> >
>>>>> > > > >> > I have arranged a call with Matthew.
>>>>> > > > >> >
>>>>> > > > >> > Simon
>>>>> > > > >> >
>>>>> > > > >> > On Thu, 9 Jan 2025 at 06:31, Arnaud Spiwack
>>>>> > > > >> > <[17]arnaud.spiwack at tweag.io
>>>>> > <mailto:[18]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]https://github.com/ghc-proposals/ghc-proposals/pull/682
>>>>> > > > >> > <
>>>>> > > > >> [20]
>>>>> 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]https://moduscreate.com
>>>>> > > > >> > <[22]https://moduscreate.com> and
>>>>> > [23]https://tweag.io
>>>>> > > > >> > <[24]https://tweag.io>.
>>>>> > > > >>
>>>>> > > > >>
>>>>> > > > >> --
>>>>> > > > >> Adam Gundry, Haskell Consultant
>>>>> > > > >> Well-Typed LLP, [25]https://www.well-typed.com/
>>>>> > > > >>
>>>>> > > > >> Registered in England & Wales, OC335890
>>>>> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England
>>>>> > > > >>
>>>>> > > > >> _______________________________________________
>>>>> > > > >> ghc-steering-committee mailing list
>>>>> > > > >> [26]ghc-steering-committee at haskell.org
>>>>> > > > >>
>>>>> > [27]
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
>>>>> > ommittee
>>>>> > > > >>
>>>>> > > > > _______________________________________________
>>>>> > > > > ghc-steering-committee mailing list
>>>>> > > > > [28]ghc-steering-committee at haskell.org
>>>>> > > > >
>>>>> > [29]
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
>>>>> > ommittee
>>>>> > > > >
>>>>> > > >
>>>>> > > >
>>>>> > > > --
>>>>> > > > Arnaud Spiwack
>>>>> > > > Director, Research at [30]https://moduscreate.com and
>>>>> > [31]https://tweag.io.
>>>>> > >
>>>>> > >
>>>>> > > --
>>>>> > >
>>>>> >
>>>>> --------------------------------------------------------------------
>>>>> > --
>>>>> > > Erik de Castro Lopo
>>>>> > > [32]http://www.mega-nerd.com/
>>>>> > >
>>>>> >
>>>>> > --
>>>>> >
>>>>> --------------------------------------------------------------------
>>>>> > --
>>>>> > Erik de Castro Lopo
>>>>> > [33]http://www.mega-nerd.com/
>>>>> > _______________________________________________
>>>>> > ghc-steering-committee mailing list
>>>>> > [34]ghc-steering-committee at haskell.org
>>>>> > [35]
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
>>>>> > ommittee
>>>>> >
>>>>> > --
>>>>> >
>>>>> > Arnaud Spiwack
>>>>> > Director, Research at [36]https://moduscreate.com and
>>>>> > [37]https://tweag.io.
>>>>> >
>>>>> > References
>>>>> >
>>>>> > 1. mailto:erikd at mega-nerd.com
>>>>> > 2.
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
>>>>> > 3.
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126
>>>>> > 4. mailto:simon.peytonjones at gmail.com
>>>>> > 5. mailto:adam at well-typed.com
>>>>> > 6.
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243
>>>>> > 7. https://github.com/ghc-proposals/ghc-proposals/pull/682
>>>>> > 8.
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
>>>>> > 9. mailto:simon.peytonjones at gmail.com
>>>>> > 10. mailto:simon.peytonjones at gmail.com
>>>>> > 11.
>>>>> https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing
>>>>> > 12. mailto:arnaud.spiwack at tweag.io
>>>>> > 13. mailto:arnaud.spiwack at tweag.io
>>>>> > 14. mailto:simon.peytonjones at gmail.com
>>>>> > 15. mailto:simon.peytonjones at gmail.com
>>>>> > 16.
>>>>> https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116
>>>>> > 17. mailto:arnaud.spiwack at tweag.io
>>>>> > 18. mailto:arnaud.spiwack at tweag.io
>>>>> > 19. https://github.com/ghc-proposals/ghc-proposals/pull/682
>>>>> > 20. https://github.com/ghc-proposals/ghc-proposals/pull/682
>>>>> > 21. https://moduscreate.com/
>>>>> > 22. https://moduscreate.com/
>>>>> > 23. https://tweag.io/
>>>>> > 24. https://tweag.io/
>>>>> > 25. https://www.well-typed.com/
>>>>> > 26. mailto:ghc-steering-committee at haskell.org
>>>>> > 27.
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> > 28. mailto:ghc-steering-committee at haskell.org
>>>>> > 29.
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> > 30. https://moduscreate.com/
>>>>> > 31. https://tweag.io/
>>>>> > 32. http://www.mega-nerd.com/
>>>>> > 33. http://www.mega-nerd.com/
>>>>> > 34. mailto:ghc-steering-committee at haskell.org
>>>>> > 35.
>>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>>>> > 36. https://moduscreate.com/
>>>>> > 37. 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
>>>>>
>>>>> _______________________________________________
>>>>> 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.
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and 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/20250221/fda5a556/attachment-0001.html>
More information about the ghc-steering-committee
mailing list