- ghc-steering-committee

Please review #517: Require implementors before proposal submission, Shepherd: Simon PJ
by Joachim Breitner 19 Oct '22

19 Oct '22

Dear Committee, I have submitted a meta-proposal to require implementors to be named before proposal submission, to focus on those proposals that are likely to be actually implemented. https://github.com/ghc-proposals/ghc-proposals/pull/517 Because this is a process-related proposal, I’d like to ask Simon to shepherd it. 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/

9 23

Proposal #522: Or patterns. Recommendation: accept
by Richard Eisenberg 18 Oct '22

18 Oct '22

Hi all, I have been assigned to shepherd Proposal #522, Or patterns. Proposal text: https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patt… Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/522 The proposal introduces a syntax for or-patterns. Here is an example: case ... of K1 a b c -> Just ... K2 d e -> Just ... (K3 {} ; K4 {} ; K5 {}) -> Nothing Summary Without this proposal, the author of the above code would have to either use a _ pattern for the last line, meaning that future new constructors added to the datatype would go unreported by compiler warnings, or to write the K3, K4, and K5 cases separately, repeating the right-hand side. Or-patterns are common in other languages. The authors include a nice section (https://github.com/knothed/ghc-proposals/blob/master/proposals/0522-or-patt…) on alternative syntax. I recommend reading it; it made me feel better about the proposed semi-colon syntax. The proposal requires that each pattern in an or-pattern must not bind any variables. Any provided contexts (e.g. GADT equalities) and existential variables are ignored, and any required context is combined across the disjuncts in the pattern. Two implementors are named in the proposal. Recommendation I recommend acceptance. This proposal is relatively simple, will lead to a nice quality-of-life improvement, is future-compatible (*) with or-patterns that do bind variables/contexts/existentials, and has a natural reading to users unfamiliar with the extension. (*): I suppose that the fact that an or-pattern discards equalities might mean that a later improvement that retains these equalities might interfere with type inference (because in-scope equalities cause type variables to become untouchable). But I will choose not to worry about this. The downsides are: - Yet another feature to think about, including a new extension name. - Yet another feature to implement and maintain. I think the improvements to the language are worth these downsides, though I could be convinced otherwise. Please let me know what you think about this proposal. I'm hoping to accept this proposal in three weeks (a bit longer than my usual timeframe, due to it being a popular time for holidays), unless there is objection. Thanks! Richard

5 5

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 06 Oct '22

06 Oct '22

Dear Haskell community, the GHC Steering committee is seeking nominations for one or more new members. The committee scrutinizes, nitpicks, improves, weighs 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. 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 maintain in perpetuity in GHC's code base, to learn, and to deal with 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 seek a balance of background, expertise, and views on the committee. Membership of the committee gives you the chance to influence the future direction of Haskell, and to serve the Haskell community. 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. To nominate yourself, 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. On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Call for nominations coming up
by Joachim Breitner 03 Oct '22

03 Oct '22

Dear Committee, with Baldurs resignation, we now have 8 non-expiring member (Arnaud’s term has expired in July) and we ought to do a new call for nominations. Arnaud is of course very welcome to re-nominate himself, and I personally hope he will. Do you have any suggestions for improvements to the process? This is the mail I sent around last time – do you want to to change anything there? https://mail.haskell.org/pipermail/ghc-steering-committee/2022-January/0027… Should I maybe remove the paragraph asking for “conservative members”? Also maybe think of people you’d personally like to nudge to apply. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #516: Introduce `-Wincomplete-record-selectors`, Shepherd: Eric
by Joachim Breitner 02 Oct '22

02 Oct '22

Dear Committee, Introduce `-Wincomplete-record-selectors` have been submitted by Adam Gundry https://github.com/ghc-proposals/ghc-proposals/pull/516 https://github.com/adamgundry/ghc-proposals/blob/incomplete-record-selector… I suggest that Eric shepherds this proposal. 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 10

Please review #518: Type vs Constraint proposal, Shepherd: Eric
by Joachim Breitner 02 Oct '22

02 Oct '22

Dear Committee, The Type vs Constraint proposal has been submitted by Richard Eisenberg and Simon Peyton Jones https://github.com/ghc-proposals/ghc-proposals/pull/518 https://github.com/ghc-proposals/ghc-proposals/blob/spj/type-vs-constraint/… I suggest that Eric shepherds this proposal. 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/

5 10

Baldur stepping down
by Simon Peyton Jones 26 Sep '22

26 Sep '22

Friends I'm writing to let you know that Baldur (icelandjack) has decided to step down from the GHC Steering Committee. He is incredibly talented, but the commitments of his job and a newborn daughter (congratulations Baldur) have made it hard for him to keep up with GHC proposals. Thank you Baldur. You have given a lot to Haskell already (notably deriving via) and I'm sure there is lots more to come. best wishes Simon

1 0

Proposal #270: Support pun-free code. Recommendation: accept
by Chris Dornan 08 Sep '22

08 Sep '22

Hi all, I have been assigned to shepherd Proposal #270: Support pun-free code Proposal text: https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… Proposal discussion: https://github.com/ghc-proposals/ghc-proposals/pull/270 The proposal helps manage @data T = T@ style definitions that use the same name for type and data constructors. It introduces -Wpuns and -Wpun-bind to warn about puns at usage and binding sites, respectively, and adds qualified import syntax for importing selectively into the data and type name spaces: import Data.Proxy type qualified as T -- import only the type namespace import Data.Proxy data qualified as D -- import only the data namespace As the low number indicates the proposal has been around for a while and the author has an implementation PR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2044. The most active discussion point was Simon’s observation that this extension introduces a ‘fork’ in the language: https://github.com/ghc-proposals/ghc-proposals/pull/270#issuecomment-536115…. (See Simon’s comment at the link for an explanation of the Haskell language fork idea.) There is a long tradition of using data/type constructor puns (older than Haskell itself) and many people will consider it good style (I certainly do), while others do not, and they will benefit from tools to help manage and limit their use. So, notwithstanding the fork-like nature of the proposal, because it is not very intrusive (some warnings with finer control of qualified imports), and it is helping folks to establish a subset that they are maintaining anyway, I am minded to accept this proposal — though it was close. My sole concern is that it could give rise to contentious pressure on the wider Haskell community to embrace the subset. To (avoiding) this end, I suggest that we include wording in the user guide section documenting this extension to the effect that there is no consensus on the desirability or otherwise of the punful code the extension seeks to address. Chris

5 17

Please review: #515 Relaxing HasField constraints
by Tom Harding 07 Sep '22

07 Sep '22

Hi all, Ollie Charles’ proposal <https://github.com/ghc-proposals/ghc-proposals/pull/515> removes the restrictions placed on HasField instances. Close to my heart, this addresses the problem of creating custom `HasField` instances for record types. I’m in favour of this proposal as it would solve some issues I have encountered, but the floor is open for discussion. Thanks, Tom

3 2

Please review #500: Add implicit import proposal, Shepherd: Baldur
by Joachim Breitner 05 Sep '22

05 Sep '22

Dear Committee, Add implicit import proposal has been submitted by Tristan de Cacqueray This is an interesting one: At first glance it looks quite un- haskellish, but it’s hard to poing out what’s, if anything, is wrong with it. I expect that the discussion will revolve not so much about technical issues, but more about best practices and our vision for Haskell’s look and feel. https://github.com/ghc-proposals/ghc-proposals/pull/500 https://github.com/TristanCacqueray/ghc-proposals/blob/implicit-import/prop… I suggest that Baldur, as our newest committee member, gets to shepherd this one. 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 9