October 2022 - ghc-steering-committee

Please review #512: NoFieldSelectors as datatype annotation, Shepherd: Baldur
by Joachim Breitner 03 Mar '23

03 Mar '23

Dear Committee, NoFieldSelectors as datatype annotation have been proposed by Matt Parsons https://github.com/ghc-proposals/ghc-proposals/pull/512 https://github.com/parsonsmatt/ghc-proposals/blob/matt/field-selectors-scop… I suggest Baldur to shepherd 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/

9 29

#511 Deep Subsumption, recommendation: accept
by Spiwack, Arnaud 02 Jan '23

02 Jan '23

Dear all, The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal. The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces. -XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc. There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? --- Despite the fact that this extension is decidedly fork-like, and that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do. I also recommend backporting to GHC 9.2. It should essentially be backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me.

5 8

GHC2023
by Joachim Breitner 11 Nov '22

11 Nov '22

Hi Committee, when we defined the process for GHC20xx, as written in https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-g… we wrote Likely, the first iteration of this process will be vastly different from the following ones: The first one is expected to add a large number of uncontroversial extensions; so the next iteration will likely only make a smaller, but more controversial change. Therefore, this proposal does not commit to a fixed cadence. Instead, 6 months after the first release of a version of GHC that supports a GHC20xx set, we evaluate the outcome, the process, and the perceived need of a next release. At that time we will refine the processes, if needed, and set a cadence. The first version of GHC that supported GHC2021 was 9.2, released in October 2022. Last fall we said that not enough time has passed to do such an evaluation, and we skipped defining GHC2022. Another year has passed, and if we are serious with the idea that GHC20xx is a continuous thing, we should probably start defining GHC2023 – even if it is just a small delta. This e-mail tries to kickstart that process. Last time we did a relative elaborate thing where we voted on essentially _every_ extension. I think that made sense for the first iteration, where we had to winddow down the likely extensions. But now we have a base line (GHC2021), and are asked to find a suitable delta, and I’d go for a nomination-based approach: Committee members can propose adding (or removing, in theory) specific extensions, and then we vote only on those. Does that sound reasonable? Does anyone have any insight from the real world? Has GHC2021 helped our users? And if not, why not? What kind of hard data would you like to see, if any? (I’m a bit wary of spending too much time writing scripts to scrape hackage, for example to see which extensions people tend to enable _in addition_ to GHC2021, only to see that libraries on hackage are understandably slow to use default-language: GHC2021, as that’s not great for backward compat for now. But I am also not sure where to look for good data…) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 8

Welcome Adam, welcome back Arnaud
by Joachim Breitner 03 Nov '22

03 Nov '22

Dear all, Adam Gundry has nominated himself to join the committee, and was voted in, so welcome! Adam, if you haven’t done so already, please subscribe to https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee and review the processes at https://github.com/ghc-proposals/ghc-proposals/ https://github.com/ghc-proposals/ghc-proposals/blob/master/acceptance.rst https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst You should have gotten a github invite to the repo. Your opinion is valued on all proposals currently under review, even those that were submitted before. Which, conveniently, is only one at the moment and relates to records: https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… (but we do look forward to your opinion about proposals about other corners of the language, of course :-)) Arnaud has also nominated himself and was voted back in for another term. Thanks for staying with us! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 4

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