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@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@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@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@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@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@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@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@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@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@gmail.com > mailto:[10][19]simon.peytonjones@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@tweag.io > mailto:[13][22]arnaud.spiwack@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@gmail.com > > > >> > mailto:[15][24]simon.peytonjones@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@tweag.io > mailto:[18][27]arnaud.spiwack@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@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@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@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@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@gmail.com > 5. mailto:[51]adam@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@gmail.com > 10. mailto:[56]simon.peytonjones@gmail.com > 11. [57]https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R Phk5MslruY7yXD0/edit?usp=sharing > 12. mailto:[58]arnaud.spiwack@tweag.io > 13. mailto:[59]arnaud.spiwack@tweag.io > 14. mailto:[60]simon.peytonjones@gmail.com > 15. mailto:[61]simon.peytonjones@gmail.com > 16. [62]https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ estreview-2562175116 > 17. mailto:[63]arnaud.spiwack@tweag.io > 18. mailto:[64]arnaud.spiwack@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@haskell.org > 27. [73]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee > 28. mailto:[74]ghc-steering-committee@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@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@haskell.org > [85]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [86]ghc-steering-committee@haskell.org [87]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c ommittee
_______________________________________________ ghc-steering-committee mailing list [88]ghc-steering-committee@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@gmail.com 2. mailto:arnaud.spiwack@tweag.io 3. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2651558... 4. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2671436... 5. mailto:arnaud.spiwack@tweag.io 6. mailto:arnaud.spiwack@tweag.io 7. https://github.com/well-typed/ghc-proposals/blob/wip/level-imports-2024/prop... 8. mailto:simon.peytonjones@gmail.com 9. mailto:malte.ott@maralorn.de 10. mailto:erikd@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@gmail.com 14. mailto:adam@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@gmail.com 19. mailto:simon.peytonjones@gmail.com 20. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58R 21. mailto:arnaud.spiwack@tweag.io 22. mailto:arnaud.spiwack@tweag.io 23. mailto:simon.peytonjones@gmail.com 24. mailto:simon.peytonjones@gmail.com 25. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequ 26. mailto:arnaud.spiwack@tweag.io 27. mailto:arnaud.spiwack@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@haskell.org 36. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c 37. mailto:ghc-steering-committee@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@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@mega-nerd.com 48. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 49. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609583... 50. mailto:simon.peytonjones@gmail.com 51. mailto:adam@well-typed.com 52. https://github.com/ghc-proposals/ghc-proposals/pull/682#discussion_r18491232... 53. https://github.com/ghc-proposals/ghc-proposals/pull/682 54. https://github.com/ghc-proposals/ghc-proposals/pull/682#issuecomment-2609199... 55. mailto:simon.peytonjones@gmail.com 56. mailto:simon.peytonjones@gmail.com 57. https://docs.google.com/document/d/1dEMPIHpbN19xYZymGCxO0BpQR58RPhk5MslruY7y... 58. mailto:arnaud.spiwack@tweag.io 59. mailto:arnaud.spiwack@tweag.io 60. mailto:simon.peytonjones@gmail.com 61. mailto:simon.peytonjones@gmail.com 62. https://github.com/ghc-proposals/ghc-proposals/pull/682#pullrequestreview-25... 63. mailto:arnaud.spiwack@tweag.io 64. mailto:arnaud.spiwack@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@haskell.org 73. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 74. mailto:ghc-steering-committee@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@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@haskell.org 85. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 86. mailto:ghc-steering-committee@haskell.org 87. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 88. mailto:ghc-steering-committee@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/