September 2022 - ghc-steering-committee

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

02 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

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

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