December 2021 - ghc-steering-committee

Please review #451: Sized literals proposal; Shepherd: Simon M
by Richard Eisenberg 23 Apr '22

23 Apr '22

Dear Committee, This is your interim secretary speaking: Sized literals proposal, proposing syntax for literals for the new sized primitive numeric types, has been proposed by Sylvain Henry. https://github.com/ghc-proposals/ghc-proposals/pull/451 https://github.com/hsyl20/ghc-proposals/blob/sized-literals/proposals/0000-… I propose Simon M as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Richard

4 4

#425: invisible binders in type declarations; rec: accept
by Richard Eisenberg 07 Apr '22

07 Apr '22

Hi all, I am the shepherd for proposal #425, https://github.com/ghc-proposals/ghc-proposals/pull/425, proposing to add invisible binders in type declarations. The main payload of the proposal is to allow definitions like > data Proxy @k (a :: k) = Proxy instead of today's > data Proxy (a :: k) = Proxy which has no explicit binding site for k. This new syntax solves a number of smallish syntax conundra, as very well outlined in the proposal. In addition, the proposal includes two small unrelated tweaks to the syntax of type family instances; these are points (6) and (7) in the proposal. Both changes will break some obscure (but still realistic, knowing Haskell) programs, but both fixes are backward compatible. --- I recommend acceptance. The proposal is motivated nicely (do check out the examples) and solves a real problem. The new syntax fits in with other similar features. The small cleanups to existing syntax will lead to better error messages. The one drawback, as I see it, is that this proposal includes point (5), which is a breaking change to the way type synonyms work. Right now, we can say > type P = (Proxy :: k -> Type) and GHC will infer P :: forall k. k -> Type. Under this proposal, you would have to write > type P @k = (Proxy :: k -> Type) bringing k into scope explicitly. The fix is not backward compatible, and so I think this proposal should come with a migration strategy, where we warn about the former version for some releases before banning it. (Continuing to support it is possible, but it's very awkward to have a variable mentioned only in a synonym's right-hand side.) Sorry for the delay in producing this recommendation! Richard

5 8

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 #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

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

17 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

GHC Steering Committee Status
by Joachim Breitner 15 Dec '21

15 Dec '21

Dear Committee, I hope you all had a lovely fall. Three months since the last status mail! High time for a new one. So what has happened since the last one? * Simon suggested a better way to keep tabs on what’s going on, and you’ll find the second have of this mail at https://github.com/ghc-proposals/ghc-proposals/wiki/Status I still didn’t get around to mess with markdown tables etc… sorry. If someone feels inspired for how that wiki page would look better, ideally with markup that I can easily edit and include in this email, suggestions are welcome. * Alejandro announced to step down once through with his currently shepherded proposals. * We decided to not define GHC2022. * we were asked to review these proposals: #433: the Unsatisfiable constraint #452: Articulate principles for GHC evolution #451: Sized literals proposal #460: migration plan for non-magical-~ * we have a recommendation from the shepherd about: #400: COMPLETE set signatures; rec: accept #425: invisible binders in type declarations; rec: accept #433: the Unsatisfiable constraint; recommendation: accept * we have sent the following proposals back to revision #412: Explicit Splice Imports #400: COMPLETE set signatures #283: Local modules * we decided about the following proposals #302: Multiway lambda (accept) #409: Exportable named defaults (accept) #281: Visible "forall" in terms (accept) #433: the Unsatisfiable constraint; recommendation: accept We currently have to act on the following 6 proposals, down by 3: ## Waiting for committee decision #452: Articulate principles for GHC evolution (Shepherd: SPJ) 2021-12-15: Ongoing discussion, heading for acceptance #425: Invisible binders in type declarations, Shepherd: Richard 2021-10-19: Recommendation to accept #392: Clarify modifiers design principle (Shepherd: Alejandro) 2021-07-23: Alejandro asked for more eyes. Discussion about grammar and compatibility with #390 open Richard posted last. Please follow up! #319: NoFallibleDo, Shepherd: Alejandro 2021-07-23: Rejection recommended Continued silence since the last update. Committee comments please? ## Waiting for Shepherd action #451: Sized Literals, Shepherd: Simon M. 2021-11-19: Assigned to Simon M. Simon, what do you think of this? #460: migration plan for non-magical-~, Shepherd: Richard 2021-12-15: Assigned to Richard Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #460: migration plan for non-magical-~ Shepherd: Richard
by Joachim Breitner 15 Dec '21

15 Dec '21

Dear Committee, this is your secretary speaking (who is back from travels): Vlad proposed an amendment to #371 (Export ~ from Data.Type.Equality) to improve the migration plan https://github.com/ghc-proposals/ghc-proposals/pull/460 Following the tradition that amendments are shepherded by the same shepherd as the original proposal, this falls on Richard. 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

#433: the Unsatisfiable constraint; recommendation: accept
by Tom Harding 08 Dec '21

08 Dec '21

Hi all, Since I last emailed the committee, Adam has split the proposal into two parts: one for `Unsatisfiable` and one for `Warning`. I think I’m right in saying that everyone who has voiced an opinion has been in favour of the `Unsatisfiable` half, so if no one has any further thoughts, I suggest we accept this half and continue discussing `Warning` later on. Thanks, Tom

2 2