- ghc-steering-committee

#301: Rename PtrRep to BoxedRep, recommending: accept
by Joachim Breitner 17 Dec '19

17 Dec '19

Dear Committee, this is your secretary speaking: Rename PtrRep to BoxedRep has been proposed by Neil Andrew Martin https://github.com/ghc-proposals/ghc-proposals/pull/301 I’ll shepherd that myself. It’s a simple renaming in an existing proposal, clarifying a somewhat misleading name (PtrRep) to a more precise one (BoxedRep). This looks reasonable and helpful, so I am happy to propose acceptance. Any objections? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5

RecordDotSyntax: please express a view
by Simon Peyton Jones 16 Dec '19

16 Dec '19

Dear steering committee I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282 I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477… Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views. Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion. I'd love every member of the committee to express a view. This proposal has attracted a lot of interest. Thanks Simon | -----Original Message----- | From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org> | On Behalf Of Joachim Breitner | Sent: 28 November 2019 10:11 | To: ghc-steering-committee(a)haskell.org | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282: | RecordDotSyntax, Shepherd: Simon PJ | | Dear Committee, | | this is your secretary speaking: | | RecordDotSyntax language extension proposal has been proposed by Neil | Mitchell and Shayne Fletcher | https://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | syntax/proposals/0000-record-dot-syntax.md | | This is going to be a tricky one. It is partly about whitespace, so it | has attracted a _lot_ of community interest, by far the most so far. To | navigate that ship, I propose Simon PJ as the shepherd, because he is a | excellent moderator and community manager, and because he has the | necessary authority to hopefully get a verdict accepted. | | Please reach consensus as described in | https://github.com/ghc-proposals/ghc-proposals#committee-process | I suggest you make a recommendation, in a new e-mail thread with the | proposal number in the subject, about the decision, maybe point out | debatable points, and assume that anyone who stays quiet agrees with you. | | Thanks, | Joachim | -- | Joachim Breitner | mail(a)joachim-breitner.de | http://www.joachim-breitner.de/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee(a)haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

9 23

Atze Dijkstra is ghc-proposals repo admin?
by Joachim Breitner 16 Dec '19

16 Dec '19

Hi Atze, dear committee, I noticed that Atze Dijkstra is a GitHub admin for the https://github.com/ghc-proposals/ghc-proposals repo. Is that intentional? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

Status
by Joachim Breitner 16 Dec '19

16 Dec '19

Dear Committee, since the last status, it seems we have become much more willing to send proposals back for revision. (BTW, you can make my life easier to always mention a status change like this on the mailing list.) Also, * Sandy Maguire stepped down, and we started a call for nominations. (I have already received two self-nominations) * we were asked to review these proposals: #177: Simple constrained type families, Shepherd: Richard #273: Local Types, Shepherd: Eric #285: -XNoImplicitForAll, Shepherd: Simon Marlow #246: Overloaded Quotations, Shepherd: Simon PJ #265: Unlifted Datatypes, Shepherd: Simon Marlow #282: RecordDotSyntax, Shepherd: Simon PJ #301: Rename PtrRep to BoxedRep, Shepherd: Joachim * we have a recommendation from the shepherd about: #195: newtype Q (Texp a) (rec: accept) #285: -XNoImplicitForAll (rec: accept) #246: Overloaded Quotations (rec: accept) #194: Updated partial type signatures (rec: accept) #293: Tweaks to #229 (rec: accept) #273: Local Types (rec: needs revision) #265: Unlifted Datatypes (rec: accept) #301: Rename PtrRep to BoxedRep (rec: accept) * we have sent the following proposals back to revision #177: Simple constrained type families #285: -XNoImplicitForAll #273: Local Types #194: Updated partial type signatures #195: newtype Q (Texp a) #274: Quick Look Impredicativity (rec: accept) * we decided about the following proposals #246: Overloaded Quotations (accept) #293: Tweaks to #229 (accept) We currently have to act on the following 2 proposals, down by one! ## Waiting for Shepherd action RecordDotSyntax language extension proposal Shepherd: Simon PJ https://github.com/ghc-proposals/ghc-proposals/pull/282 (Being a prime example of Wadler’s law, it may come to voting.) ## Waiting for committee decision Rename PtrRep to BoxedRep Shepherd: Joachim https://github.com/ghc-proposals/ghc-proposals/pull/301 Acceptance imminent. Cheers and merry Christmas to those who care about that, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Precedence of r.x
by Simon Peyton Jones 12 Dec '19

12 Dec '19

A question for the committee. What does f r.x mean, where there is no white space on either side of the dot? A. The proposal says it means (f (r.x)) B. Joachim wants it to mean ((f r).x) In trying to guide the discussion to a conclusion I proposed to fix on (A). I don't think it was controversial in the public discussion, it's compatible with qualified names, and forcing `f (r.x)` looks horribly clumsy to me. Partly it's a question of whether your starting point is (a) "." is fundamentally an operator, albeit with some special extra rules, or (b) R.x, r.x, and .x are new syntactic forms, unrelated to the infix operator (.) I'm definitely thinking of it in the latter way. I don't really want to re-open this question, and I'm not sure if the authors of the proposal could live with (B). However, if the committee wants to reopen the question, then that is what we should do. Can you express a view on this narrow question? Simon

7 8

Stepping down
by Sandy Maguire 12 Dec '19

12 Dec '19

Hi all, Regrettably, I've decided to step down from the steering committee. My heart simply isn't in Haskell these days, and I'd prefer to give up my membership to someone more capable of doing good with it. For my replacement, I'd like to nominate Tom Harding and Chris Penner (both cc'd). I don't know of anyone else in the community who is as smart or dedicated as these two. Both have solid industrial credentials to help diversify the otherwise academic committee. The community at large would be very lucky to have either of them helping to steer. It's been an honour to serve with you all. Best, Sandy

5 5

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246)
by Simon Peyton Jones 06 Dec '19

06 Dec '19

Dear Steering Committee I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review. Matthew has revised his proposal #246 Overloaded Quotations<https://github.com/mpickering/ghc-proposals/blob/overloaded-proposal/propos…>. One particular point is that it does explicitly apply to Typed Template Haskell, not just untyped (see “Proposed changes” item 6). Moreover he has an implementation here: https://gitlab.haskell.org/ghc/ghc/merge_requests/2247 I recommended back in Nov that we accept (see attached email), but I asked him to make some revisions (as you can see in the discussion thread). All of this connects to (and I believe is compatible with) #195 (make Q (TExp a) into a newtype),<https://github.com/ghc-proposals/ghc-proposals/pull/195> which we are set to accept too, once the proposal is revised. Iavor: you are the shepherd for that. I’ve had support for acceptance from * Joachim * Eric * Sandy * Simon M * Richard * Arnaud * Iavor I would love to hear from * Chris A * Vitaly B Others: reply only if you have any comments on the revised proposal. I’ll accept this at the end of the week. Simon From: Matthew Pickering <notifications(a)github.com> Sent: 04 December 2019 13:58 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Mention <mention(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] Overloaded Quotation Brackets (#246) I have completed the revisions and wish to resubmit the proposal to the committee. The implementation is also finished an ready for review. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.

2 4

Please review #282: RecordDotSyntax, Shepherd: Simon PJ
by Joachim Breitner 28 Nov '19

28 Nov '19

Dear Committee, this is your secretary speaking: RecordDotSyntax language extension proposal has been proposed by Neil Mitchell and Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/282 https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/… This is going to be a tricky one. It is partly about whitespace, so it has attracted a _lot_ of community interest, by far the most so far. To navigate that ship, I propose Simon PJ as the shepherd, because he is a excellent moderator and community manager, and because he has the necessary authority to hopefully get a verdict accepted. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Managing github notifications?
by Sandy Maguire 26 Nov '19

26 Nov '19

Hi all, I'm wondering if anyone has a good strategy for dealing with github noise. Right now I feel like I need to choose between silence and overwhelming volume, and neither is good for me to do my job on this committee. I'd like to be informed when someone opens a new proposal PR in order to read it, but not for any of the follow-up commentary. As best I can tell, there is no github option that allows for this. Any advice on this would be greatly appreciated. Thanks, Sandy -- I'm currently travelling the world, sleeping on people's couches and doing full-time collaboration on Haskell projects. If this seems interesting to you, please consider signing up as a host! https://isovector.github.io/erdos/

3 2

Please review #273: Local Types, Shepherd: Eric
by Joachim Breitner 26 Nov '19

26 Nov '19

Dear Committee, this is your secretary speaking: Local Types has been updated by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/273 https://github.com/treeowl/ghc-proposals/blob/local-types/proposals/0000-lo… I propose Eric as the shepherd. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process I suggest you make a recommendation, in a new e-mail thread with the proposal number in the subject, about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 7