[ghc-steering-committee] #682: Explicit Level Imports, recommendation: accept
Malte Ott
malte.ott at maralorn.de
Mon Feb 10 08:48:13 UTC 2025
Yes, Arnaud, that was my point, thank you. People voiced opinions about syntax
and I didn’t want to silently ignore them.
I, however, retract my point about the proposal being ambiguous regarding
ImportQualifiedPost. I actually think the specification is clear. Now it is up
to us to consider the alternatives. If the rest of the committee does not think
that any of the listed syntactic alternatives have merit, I am fine with that.
I am not super convinced by Richards argument because I am sceptical that (all)
code formatters would implement that grouping soon. So I would consider the
proposed alternative of allowing splices after the modid.
Best,
Malte
On 2025-02-10 15:25, Arnaud Spiwack wrote:
> For the record, the syntactic alternatives can be found in [§8.5
> Syntactic
> alternatives]([1]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
> <[2]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 <[3]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][4]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][5]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec
> omm
> > 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][6]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuec
> omm
> > 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][7]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][8]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][9]https://github.com/ghc-proposals/ghc-proposals/pull/682#discus
> sio
> > 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][10]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][11]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][12]simon.peytonjones at gmail.com
> > <mailto:[10][13]simon.peytonjones at gmail.com>>
> > > > >> wrote:
> > > > >> >
> > > > >> > Matthew and I had a good conversation. Some
> notes here
> > > > >> > <
> > > > >>
> >
> [11][14]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][15]arnaud.spiwack at tweag.io
> > <mailto:[13][16]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][17]simon.peytonjones at gmail.com
> > > > >> >
> <mailto:[15][18]simon.peytonjones at gmail.com>> wrote:
> > > > >> >
> > > > >> > Arnaud
> > > > >> >
> > > > >> > I have responded with a lot of feedback
> on the
> > Github thread
> > > > >> > <
> > > > >>
> >
> [16][19]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][20]arnaud.spiwack at tweag.io
> > <mailto:[18][21]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][22]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > > > >> > <
> > > > >>
> [20][23]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][24]https://moduscreate.com
> > > > >> > <[22][25]https://moduscreate.com>
> and
> > [23][26]https://tweag.io
> > > > >> > <[24][27]https://tweag.io>.
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Adam Gundry, Haskell Consultant
> > > > >> Well-Typed LLP, [25][28]https://www.well-typed.com/
> > > > >>
> > > > >> Registered in England & Wales, OC335890
> > > > >> 27 Old Gloucester Street, London WC1N 3AX, England
> > > > >>
> > > > >> _______________________________________________
> > > > >> ghc-steering-committee mailing list
> > > > >> [26][29]ghc-steering-committee at haskell.org
> > > > >>
> >
> [27][30]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> ng-c
> > ommittee
> > > > >>
> > > > > _______________________________________________
> > > > > ghc-steering-committee mailing list
> > > > > [28][31]ghc-steering-committee at haskell.org
> > > > >
> >
> [29][32]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> ng-c
> > ommittee
> > > > >
> > > >
> > > >
> > > > --
> > > > Arnaud Spiwack
> > > > Director, Research at [30][33]https://moduscreate.com and
> > [31][34]https://tweag.io.
> > >
> > >
> > > --
> > >
> >
> --------------------------------------------------------------------
> > --
> > > Erik de Castro Lopo
> > > [32][35]http://www.mega-nerd.com/
> > >
> >
> > --
> >
> --------------------------------------------------------------------
> > --
> > Erik de Castro Lopo
> > [33][36]http://www.mega-nerd.com/
> > _______________________________________________
> > ghc-steering-committee mailing list
> > [34][37]ghc-steering-committee at haskell.org
> >
> [35][38]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steeri
> ng-c
> > ommittee
> >
> > --
> >
> > Arnaud Spiwack
> > Director, Research at [36][39]https://moduscreate.com and
> > [37][40]https://tweag.io.
> >
> > References
> >
> > 1. mailto:[41]erikd at mega-nerd.com
> > 2.
> [42]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> ment-2609199731
> > 3.
> [43]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> ment-2609583126
> > 4. mailto:[44]simon.peytonjones at gmail.com
> > 5. mailto:[45]adam at well-typed.com
> > 6.
> [46]https://github.com/ghc-proposals/ghc-proposals/pull/682#discussi
> on_r1849123243
> > 7. [47]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 8.
> [48]https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecom
> ment-2609199731
> > 9. mailto:[49]simon.peytonjones at gmail.com
> > 10. mailto:[50]simon.peytonjones at gmail.com
> > 11.
> [51]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
> Phk5MslruY7yXD0/edit?usp=sharing
> > 12. mailto:[52]arnaud.spiwack at tweag.io
> > 13. mailto:[53]arnaud.spiwack at tweag.io
> > 14. mailto:[54]simon.peytonjones at gmail.com
> > 15. mailto:[55]simon.peytonjones at gmail.com
> > 16.
> [56]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
> estreview-2562175116
> > 17. mailto:[57]arnaud.spiwack at tweag.io
> > 18. mailto:[58]arnaud.spiwack at tweag.io
> > 19. [59]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 20. [60]https://github.com/ghc-proposals/ghc-proposals/pull/682
> > 21. [61]https://moduscreate.com/
> > 22. [62]https://moduscreate.com/
> > 23. [63]https://tweag.io/
> > 24. [64]https://tweag.io/
> > 25. [65]https://www.well-typed.com/
> > 26. mailto:[66]ghc-steering-committee at haskell.org
> > 27.
> [67]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
> > 28. mailto:[68]ghc-steering-committee at haskell.org
> > 29.
> [69]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
> > 30. [70]https://moduscreate.com/
> > 31. [71]https://tweag.io/
> > 32. [72]http://www.mega-nerd.com/
> > 33. [73]http://www.mega-nerd.com/
> > 34. mailto:[74]ghc-steering-committee at haskell.org
> > 35.
> [75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
> > 36. [76]https://moduscreate.com/
> > 37. [77]https://tweag.io/
>
> > _______________________________________________
> > ghc-steering-committee mailing list
> > [78]ghc-steering-committee at haskell.org
> >
> [79]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
>
> _______________________________________________
> ghc-steering-committee mailing list
> [80]ghc-steering-committee at haskell.org
> [81]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
>
> _______________________________________________
> ghc-steering-committee mailing list
> [82]ghc-steering-committee at haskell.org
> [83]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> ommittee
>
> --
> Arnaud Spiwack
> Director, Research at [84]https://moduscreate.com and
> [85]https://tweag.io.
>
> References
>
> 1. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/proposals/0000-splice-imports.rst#syntactic-alternatives
> 2. mailto:simon.peytonjones at gmail.com
> 3. mailto:malte.ott at maralorn.de
> 4. mailto:erikd at mega-nerd.com
> 5. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> 6. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> 7. mailto:simon.peytonjones at gmail.com
> 8. mailto:adam at well-typed.com
> 9. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussio
> 10. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 11. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomm
> 12. mailto:simon.peytonjones at gmail.com
> 13. mailto:simon.peytonjones at gmail.com
> 14. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R
> 15. mailto:arnaud.spiwack at tweag.io
> 16. mailto:arnaud.spiwack at tweag.io
> 17. mailto:simon.peytonjones at gmail.com
> 18. mailto:simon.peytonjones at gmail.com
> 19. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ
> 20. mailto:arnaud.spiwack at tweag.io
> 21. mailto:arnaud.spiwack at tweag.io
> 22. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 23. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 24. https://moduscreate.com/
> 25. https://moduscreate.com/
> 26. https://tweag.io/
> 27. https://tweag.io/
> 28. https://www.well-typed.com/
> 29. mailto:ghc-steering-committee at haskell.org
> 30. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> 31. mailto:ghc-steering-committee at haskell.org
> 32. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c
> 33. https://moduscreate.com/
> 34. https://tweag.io/
> 35. http://www.mega-nerd.com/
> 36. http://www.mega-nerd.com/
> 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. mailto:erikd at mega-nerd.com
> 42. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> 43. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583126
> 44. mailto:simon.peytonjones at gmail.com
> 45. mailto:adam at well-typed.com
> 46. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r1849123243
> 47. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199731
> 49. mailto:simon.peytonjones at gmail.com
> 50. mailto:simon.peytonjones at gmail.com
> 51. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7yXD0/edit?usp=sharing
> 52. mailto:arnaud.spiwack at tweag.io
> 53. mailto:arnaud.spiwack at tweag.io
> 54. mailto:simon.peytonjones at gmail.com
> 55. mailto:simon.peytonjones at gmail.com
> 56. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-2562175116
> 57. mailto:arnaud.spiwack at tweag.io
> 58. mailto:arnaud.spiwack at tweag.io
> 59. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 60. https://github.com/ghc-proposals/ghc-proposals/pull/682
> 61. https://moduscreate.com/
> 62. https://moduscreate.com/
> 63. https://tweag.io/
> 64. https://tweag.io/
> 65. https://www.well-typed.com/
> 66. mailto:ghc-steering-committee at haskell.org
> 67. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 68. mailto:ghc-steering-committee at haskell.org
> 69. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 70. https://moduscreate.com/
> 71. https://tweag.io/
> 72. http://www.mega-nerd.com/
> 73. http://www.mega-nerd.com/
> 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. mailto:ghc-steering-committee at haskell.org
> 79. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 80. mailto:ghc-steering-committee at haskell.org
> 81. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 82. mailto:ghc-steering-committee at haskell.org
> 83. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> 84. https://moduscreate.com/
> 85. https://tweag.io/
More information about the ghc-steering-committee
mailing list