- ghc-steering-committee

Please review #609: (p1; p2) for or-patterns, Shepherd: Chris
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, Sebastian Graf and David Knothe have reasons to revisit the Or-patterns proposal (#522) and change the syntax, also based on a series of popular votes. https://github.com/ghc-proposals/ghc-proposals/pull/609 I’d like to assign this to Chris Dornan. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #583: HasField redesign, Shepherd: Arnaud
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, Adam Gundry proposes an overhaul of the HasField type class. https://github.com/ghc-proposals/ghc-proposals/pull/583 https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposal… I’d like to assign this to Arnaud. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #608: no implicit bindings with -XPatternSignatures, Shepherd: Richard
by Joachim Breitner 17 Aug '23

17 Aug '23

Dear Committee, John Ericson continues his series of amendments to #448 (Modern Scoped Type Variables); in #608 he scales back -XPatternSignatures so that it does not include pattern signature bindings. This is quite similar to my #119 from 5 years ago. https://github.com/ghc-proposals/ghc-proposals/pull/608 I’d like to assign this to Richard as one of the experts on scoped type variables. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Away from a keyboard for a week
by Joachim Breitner 10 Aug '23

10 Aug '23

So either don’t expect swift secretarial responses, or act secretarial in my absence. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

#604: do not let -XScopedTypeVariables imply -XTypeAbstractions, rec: accept
by Joachim Breitner 03 Aug '23

03 Aug '23

Dear committee, John Ericsson in https://github.com/ghc-proposals/ghc-proposals/pull/604 proposes an amendment to #448. I’ll shepherd this myself. Status Quo: ScopedTypeVariables implies TypeAbstractions. New behavior: TypeAbstractions needs to be enabled explicitly. (Plus, as a compat feature, ScopedTypeVariables&TypeApplications enable TypeAbstractions, with a deprecation warning upon use.) John makes a good argument that it’s odd to expand the meaning of an existing extension like ScopedTypeVariables without need, and the proposed way sounds good to me, so I recommend to accept this. This is a minor change and would be good to have clarity soon. If no discussion happens, I’ll merge in a week. I am particularly keen on feedback from Richard (original author) and Arnaud (original shepherd), of course. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 5

Feedback on GHC2021 on Discourse
by Joachim Breitner 31 Jul '23

31 Jul '23

Hi, for those who are not following discourse, someone kicked up a thread asking for opinions on GHC2021: https://discourse.haskell.org/t/anybody-using-ghc2021/7095?u=nomeata It’s mostly very positive and encouraging (and I hope helps us overcome the anxiety about this and define an even better GHC2024). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Please review #597: Constraints synonyms in deriving heads, Shepherd: Moritz
by Joachim Breitner 25 Jul '23

25 Jul '23

Dear Committee, Grigorii Gerasev suggests to allow constraints type synonyms in deriving heads again. https://github.com/ghc-proposals/ghc-proposals/pull/597 https://github.com/uhbif19/ghc-proposals/blob/uhbif19/allow-constraint-type… I’d like to assign this to Moritz (mostly because most of the committee already sits on a proposal… gentle nudge). Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Base library organisation
by Simon Peyton Jones 17 Jul '23

17 Jul '23

Dear GHC Steering Committee Over the last few weeks, Ben Gamari and I have been discussing with Andrew and Julian from the Core Libraries Committee how to make the Core Libraries Committee and the GHC developers work together more fluidly; and that includes the GHC Steering Committee. We now have a fairly well fleshed out proposal here. <https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propo…> I hope you like it. As far as this committee is concerned there are two particular points of note 1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC. Section 5.1 also suggests that proposals should explicitly (in a separate section) call out - What new types and functions it defines - What existing types and functions are changed. We should add that to our template. At the moment we are just sharing the proposal with relevant stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any rough edges before making it public. So, any views? Personally I think this is a Big Step Forward. Simon

8 20

Please consider GHC Proposal #581 for acceptance.
by Moritz Angermann 16 Jul '23

16 Jul '23

Dear Steering Committee, Adam, Artyom and Chris wrote the Namespace-specified imports proposal <https://github.com/ghc-proposals/ghc-proposals/pull/581>. It seeks to make importing more impressive, allowing import statements to choose from the type and data namespaces explicitly. I believe this proposal adds value in expressiveness to import statements. After the last syntax refinement comes naturally to the language. I recommend acceptance of this proposal. Best regards, Moritz

7 7

#596: sized literals in Show, rec: accept
by Joachim Breitner 16 Jul '23

16 Jul '23

Dear committee, Krzysztof Gogolewski in https://github.com/ghc-proposals/ghc-proposals/pull/596 amends the sized literals proposal so that GHC uses the syntax 42#Int8 instead of (intToInt8# 42#) in the stock derived Show instances for data types with sized unboxed numbers. Implementation is also ready. Now that we have a syntax for these literals it’s clear that we want to use them in the show instances. There is no risk of breaking Show-Read-roundtripping, as Read instances cannot be derived (at the moment). This is a change in behavior of Show, so we should think for a moment how this affects stability. But none of the libraries in libraries/, in particularly not base, are affected by this change, according to Krzysztof. So I recommend to accept this. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 6