- ghc-steering-committee

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 29 Jan '22

29 Jan '22

Dear Haskell community, the GHC Steering committee is seeking nominations for at least two new members. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. In particular, please have a look at the bylaws at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until February 11th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Call for nominations coming up
by Joachim Breitner 29 Jan '22

29 Jan '22

Dear Committee, after Alejandro’s resignation I was checking if we have to do a new call for nominations, and at first I thought no, because we are still 9, but then I noticed that we actually missed the end of Vitaly and Eric’s three year terms, which started in Sep 2018 (time flies). So as per our bylaws, I should put out a call for nominations. Vitaly and Eric are of course welcome (and encouraged, if I may add) to re- nominated themselves. Or each other, if they like :-) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Farewell Alejandro
by Joachim Breitner 29 Jan '22

29 Jan '22

Hello all, Alejandro has stepped down from the committee, after having finished the PRs assigned to him (very honorable). Thanks Alejandro for two years of service, shepherding 6 proposals, four of which have been accepted, and your contributions to all the other discussions. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #392: Clarify modifiers design principle, Shepherd: Alejandro
by Joachim Breitner 28 Jan '22

28 Jan '22

Dear Committe, Clarify modifiers design principle has been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/392 This is an amendmend to #370, see the PR description for links to diffs etc. I propose Alejandro as the shepherd, as he shepherded #370 before. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 14

Please review #452: Articulate principles for GHC evolution; Shepherd: Simon PJ
by Richard Eisenberg 14 Jan '22

14 Jan '22

Dear Committee, This is your interim secretary speaking: Articulate principles for GHC evolution, proposing a new "principles" document to be added to the proposals repo, has been proposed by me. https://github.com/ghc-proposals/ghc-proposals/pull/452 https://github.com/goldfirere/ghc-proposals/blob/principles/principles.rst I propose Simon PJ as the shepherd, as this is something of a meta-proposal, appropriate for shepherding by our chair. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process <https://github.com/ghc-proposals/ghc-proposals#committee-process> Thanks, Richard

6 8

Please review #270: Support pun-free code, Shepherd: Vitaly
by Joachim Breitner 10 Jan '22

10 Jan '22

Dear Committee, Support pun-free code has been resubmitted by Artyom Kuznetsov https://github.com/ghc-proposals/ghc-proposals/pull/270 https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… This was previously shepherded by Iavor. I suggest that Vitaly takes over. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #319: NoFallibleDo proposal, Shepherd: Eric Seidel
by Joachim Breitner 08 Jan '22

08 Jan '22

Dear Committee, this is your secretary speaking: NoFallibleDo proposal has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/319 https://github.com/obsidiansystems/ghc-proposals/blob/no-fallible-do/propos… I propose Eric Seidel as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 18

Please review #448: Modern Scoped Type Variables, Shepherd: Arnaud
by Joachim Breitner 07 Jan '22

07 Jan '22

Dear Committee, this is your secretary speaking: We had a bunch of proposals related to scoping and type variables, and complained about that confusion. Richard built a unified proposal (or he volunteered), which is now up for consideration: https://github.com/ghc-proposals/ghc-proposals/pull/448 https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0… I propose that Arnaud shepherds this. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #454: custom type warnings Shepherd: Tom
by Joachim Breitner 05 Jan '22

05 Jan '22

Dear Committee, this is your secretary speaking (who is back from travels): Custom type warnings has been proposed by Adam https://github.com/ghc-proposals/ghc-proposals/pull/460 https://github.com/adamgundry/ghc-proposals/blob/custom-type-warnings/propo… This was extracted from #433, so I suggest that Tom shepherds this one too. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

#460: better migration for non-magical ~
by Richard Eisenberg 18 Dec '21

18 Dec '21

Hi all, I am shepherding Proposal #460, an amendment to accepted proposal #371. #371 proposed making the ~ operator completely non-magical in parsing, behaving syntactically like any other operator. It would have to be imported (though it would be exported from the Prelude, so most users get it for free), -XTypeOperators would have to be enabled, and its appearance is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but only very weakly: I gave a soft recommendation to accept, which Simon PJ trusted (but without much independent confirmation, it seems), Joachim gave a weak accept, and Alejandro and Arnaud said things mildly against (but did not quite vote for rejection). Text for accepted proposal #371: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-n… This current #460 is a small amendment to #371 that makes the migration story gentler. All current programs would continue to be accepted for 8 releases. If ~ is used in a file without TypeOperators, a warning (enabled by default) triggers, saying that the user should enable TypeOperators. This fix is backward compatible. If ~ is used when it is out of scope (say, because a module does not import the Prelude), a warning (in -Wcompat) triggers. The fix is not backward compatible, because (~) is not currently exported from the Prelude. This warning gets moved from -Wcompat to the default warning set after 2 releases. The previous migration story had no warning for a missing -XTypeOperators, meaning that some code would break immediately (although the fix is easy and backward compatible). Text for amended proposal: https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals… Amendment diff: https://github.com/ghc-proposals/ghc-proposals/pull/460/files --- I recommend acceptance, because immediate breakage of code is bad: it causes kinks in the update cycle after a GHC release. This new migration story should be gentler, and poses little implementation burden. Given the minor nature of this proposal, I will accept in one week if there is not dissent. Thanks, Richard

3 2