- ghc-steering-committee

Any future plans for HasField redesign?
by John Walker 12 May '22

12 May '22

Hello Committee, I was wondering if there are any near to middle term plans to move forward with hasField redesign which I believe is an enabler for setter with record dot syntax. The ticket ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3257) has a milestone of 9.4.1 and it looks like the proposal is done ( https://github.com/adamgundry/ghc-proposals/blob/hasfield-redesign/proposal…) pending feedback some time ago but hasn't got to discussions yet ( https://github.com/ghc-proposals/ghc-proposals/pull/0) thanks John

2 1

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

GHC Steering Committee Status
by Joachim Breitner 07 Apr '22

07 Apr '22

Dear Committee, it’s about time for my ~monthly~ quarterly status update So what has happened since the last one? * We decided 7 proposals since then. That’s pretty good! * Simon suggested a better way to keep tabs on what’s going on, and you’ll find the second half of this mail at https://github.com/ghc-proposals/ghc-proposals/wiki/Status As before, I still didn’t get around to mess with markdown tables etc… Maybe I just don’t feel the itch enough. * Membership changes! Alejandro has stepped down, Vitaly rotated out and Baldur and Chris joined. Bladur and Chris, you have been quite quiet here so far. Make yourself heard! * we were asked to review these proposals: #454: Custom type warnings (shepherd: Tom) #448: Modern Scoped Type Variables (shepherd: Arnaud) #270: Support pun-free code (resubmission; shepherd: Vitaly, later Chris) #475: New tuple and list syntax (resubmission; shepherd: Vlad) #277: Unicode ellipsis (shepherd: Joachim) * we have a recommendation from the shepherd about: #460: migration plan for non-magical-~ (rec: accept) #451: sized literals (rec: accept) #454: Custom type warnings (rec: accept) #475: New tuple and list syntax (rec: accept) #277: Unicode ellipsis (rec: accept) #425: invisible binders in type decls (rec: accept) #448: Modern Scoped Type Variables (rec: mostly accept) * we have sent the following proposals back to revision none, it seems * we decided about the following proposals #319: NoFallibleDo (reject) #392: Clarify modifiers design principle (accept) #460: migration plan for non-magical-~ (accept) #475: New tuple and list syntax (accept) #277: Unicode ellipsis (accept) #452: Articulate principles for GHC evolution (accept) #425: invisible binders in type declarations (accept) We currently have to act on the following 4 proposals, down by 2 since last update: ## Waiting for committee decision #451: Sized Literals, Shepherd: Simon M. 2022-01-11: Recommendation to accept by Simon Simon asked the committee for the color of the shed! Please all weigh in! #454: Custom type warnings, Shepherd: Tom 2022-01-13: Recommendation to accept There was contention (by Vlad) if the possible performance impact is too bad, with a bit of active discussion on Github #448: Modern Scoped Type Variables, Shepherd: Arnaud 2022-03-29: Arnaud makes a non-comprehensive recommendation Ongoing discussion about which parts should be accepted and which not (yet). Thanks Arnaud, for guiding the discussion. ## Waiting for Shepherd action #270: Support pun-free code, Shepherd: Chris 2022-01-01: Assigned to Chris Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

#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 #270: Support pun-free code, Shepherd: Chris Dornan
by Joachim Breitner 01 Apr '22

01 Apr '22

Dear Committee, Support pun-free code has been resubmitted (again) by Artyom Kuznetsov https://github.com/ghc-proposals/ghc-proposals/pull/270 https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… This was previously shepherded by Iavor, and then shepherded by Vitaly. I hope it’s not poisonous. I suggest that Chris takes over. 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

#477: Unicode ellipsis, recommendation: accept
by Joachim Breitner 30 Mar '22

30 Mar '22

Dear Committee, Proposal #277 “Unicode ellipsis” has been submitted by Ignat Insarov, and I’m shepherding it myself. https://github.com/ghc-proposals/ghc-proposals/pull/477 https://github.com/kindaro/ghc-proposals/blob/unicode-ellipsis/proposals/47… This is a very small proposal that lets GHC understand the nice Unicode syntax `…` in places where in ASCII world we have .., under -XUnicodeSyntax. I am fond of Unicode in general, and I expect that users of - XUnicodeSyntax expect this to work, and therefore recommend acceptance of this proposal. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 14

Please review #475: New tuple and list syntax, Shepherd: Vlad
by Joachim Breitner 24 Mar '22

24 Mar '22

Dear Committee, New syntax for tuples and lists to remove punning has been resubmitted by Richard https://github.com/ghc-proposals/ghc-proposals/pull/475 https://github.com/goldfirere/ghc-proposals/blob/tuple-syntax/proposals/000… 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/

7 18

Welcome Baldur and Chris, welcome again Eric, and Farewell Vitaly
by Joachim Breitner 11 Mar '22

11 Mar '22

Dear Committee and wider community, thanks to everyone who has put forward their nominations this round, and we are happy to welcome Chris Dornan, Baldur Blöndal and Eric Seidel as new or, in the case of Eric, re-joining members of the GHC Steering Committee! Chris and Baldur, if you haven’t already, please subscribe to our mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee and familiarize yourself with our processes at https://github.com/ghc-proposals/ghc-proposals/blob/master/README.rst and https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst You’ll find a list of proposals under discussion at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… and your opinion is welcome on all of them. The committee wants to thank Vitaly Bragilevsky for his full term of service on the committe. Your contributions were valued, and I certainly would be happy to see your nomination again at some point in the future. The next regular call for nominations (early resignations notwithstanding) will likely be in January 2023. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 6

#270: Support pun-free code, recommendation: accept
by Vitaly Bragilevsky 14 Feb '22

14 Feb '22

Dear Committee, Proposal #270 "Support pun-free code" has been resubmitted by Artyom Kuznetsov. https://github.com/ghc-proposals/ghc-proposals/pull/270 https://github.com/hithroc/ghc-proposals/blob/master/proposals/0000-support… This proposal was heavily revised since Iavor recommended rejection. As of now, it is quite thin suggesting just a couple of things: - warnings for the code with panning (understood as using same names for both types and values) - a syntax change for import declarations to reflect which names (types or values) are actually imported when importing from libraries relied on punning. The first change promotes a new style of writing Haskell code without distinguishing types and values and having a single unified namespace. We are already on that road anyway and I don't see any reason not to support this. The second change allows using an old style with punning. It could lead to doubling import declarations, but I don't think that this is really a problem. I think the proposal is mature enough so I recommend acceptance. We can also decide on the actual word used in import declarations (data, value, or pattern). I personally prefer value, but I don't see this issue as something important. Vitaly

4 3

Unimplemented proposals for GSoC
by Joachim Breitner 11 Feb '22

11 Feb '22

Hallo allerseits, Gershom suggests that maybe some of the unimplemented accepted GHC proposals might make good material for a GSoC project. You can find the (imprecise) list of such proposals at https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Apr+-label%3A%22… There are ~50 of them! Surely, a fair number of them _have_ been implemented and the tag is missing. But still… so maybe this is a good idea. Although not every proposal might have the right size and depth for a GSoC project… Is there anyone on this commmittee with a bit of experience with GSoC who might go through the list and highlight possible candidates? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0