- ghc-steering-committee

Status
by Joachim Breitner 03 May '20

03 May '20

Dear Committee, I have maintained proper social distancing from writing status mails, wisely preemptively since mid-December, but with the infection numbers going down this is no longer justifiable. Most of the time has been spent on debating and discussing the Record syntax proposal, which we eventually resolved by voting for a somewhat conservative choice. Given that I’ll try to summarize 4½ months, there might be holes. So anyways, what has happened? * Alejandro Serrano Mena, Cale Gibbard and Tom Harding have joined up. Welcome! * we were asked to review these proposals: #303: Constraint based arrow notation, Shepherd: Chis Allen #287: Simplify subsumption, Shepherd: Arnaud #302: Layout and Guards in Lambda Expressions, Shepherd: Cale #314: -Wnoncanonical-mumble-instances, Shepherd: Tom Harding #319: NoFallibleDo proposal, Shepherd: Eric Seidel #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg #270: Extend Term-Level Lookup Rules, Shepherd: Iavor (resubmission) #285: -XNoImplicitForAll, Shephard Simon M (resubmission) * we have a recommendation from the shepherd about: #282: RecordDotSyntax language extension proposal (rec: accept by vote) #287: Simplify subsumption (rec: accept) #216: Qualified Do (rec: accept one of the variants) #314: -Wnoncanonical-mumble-instances (rec: accept) #285: -XNoImplicitForAll (rec: accept) * we have sent the following proposals back to revision #216: QualifiedDo, but it’s already back * we decided about the following proposals #301: Rename PtrRep to BoxedRep (accept) #282: RecordDotSyntax language extension proposal (accept by vote) #287: Simplify subsumption (accept) #111: Linear Types (final acceptance) #314: -Wnoncanonical-mumble-instances (accept) We currently have to act on the following 7 proposals, up by 5! ## Waiting for committee decision #216: Qualified Do, Shepherd: Joachim Strong backing for one variant, but no consensus yet. Let’s keep talking (or vote!) ## Waiting for Shepherd action #285: -XNoImplicitForAll (rec: accept) acceptance imminent #302: Layout and Guards in Lambda Expressions, Shepherd: Cale #303: Constraint based arrow notation, Shepherd: Chis Allen #319: NoFallibleDo proposal, Shepherd: Eric Seidel #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg #270: Extend Term-Level Lookup Rules, Shepherd: Iavor This is already a re-submission. Cale and Chris, you have two rather old proposals on your plate. Please be considerate of our contributor’s motivation and show some activity! Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/ #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg

1 0

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] RecordDotSyntax language extension proposal (#282)
by Simon Peyton Jones 03 May '20

03 May '20

Dear GHC steering committee Shayne and Neil have updated the RecordDotSyntax proposal in the light of our conclusions. We have debated this extensively, so the question is now not so much about content as presentation: is the proposal complete, clear, and precise? I think it’s pretty good, and I propose that we now accept it as-is. I’ll take silence as assent. Please yell by close of play Weds 22 April if you’d like any further changes. Thanks! Simon From: Shayne Fletcher <notifications(a)github.com> Sent: 11 April 2020 17:59 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] RecordDotSyntax language extension proposal (#282) @simonpj<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> I'd like to invite the authors to update their proposal to incorporate (C2a) We are happy to report that the proposal has been updated as per the committee's requests. * To write out the changes to the grammar, especially how to deal with specifying aexp2.x (see Note 5) See section 2.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. * To address the question of what happens if a field name is an operator (see Note 6) See section 2.1.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. Then the committee can do a final review and sign it off. We should now like to formally request the committee's final review and sign off. We thank once again yourself and the committee for your time and consideration! — 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…>.

3 2

Please review #320: clsdfltassoctypinst in bckpck&.hs-boot, Shepherd: Richard Eisenberg
by Joachim Breitner 02 May '20

02 May '20

Dear Committee, this is your secretary speaking: Ignore class defaults for associated type instances in instances that occur in backpack and hs-boot files (a title too long for the email subject line) has been proposed by Cale https://github.com/ghc-proposals/ghc-proposals/pull/320 https://github.com/obsidiansystems/ghc-proposals/blob/signature-type-instan… I propose Richard Eisenberg as the shepherd, as he looked at it 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/

1 0

Acceptance of proposal #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 26 Apr '20

26 Apr '20

Hi all, I’ve announced the acceptance of this proposal on the GitHub thread. I had meant to do this last week, but world events have interrupted my scheduling quite a lot more than I’d like... https://github.com/ghc-proposals/ghc-proposals/pull/314#issuecomment-619588… The one outstanding question, which I think is definitely worth answering, is whether the Monad of No Return proposal currently has a shepherd. SPJ: do you know whether there’s any “active shepherding” around this proposal? Or is the current action just simply waiting for a few releases until the majority of Hackage is writing Applicative/Semigroup instances? My understanding is the latter, but I think it’s worth making it explicit somewhere. Thanks, Tom

1 0

Re: [ghc-steering-committee] Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 14 Apr '20

14 Apr '20

Hi all, My feeling is that, having incorporated Richard’s suggestions around clarity of the error, we’re broadly happy with this. This proposal was put forward two weeks ago, and it seems that those who have responded are in favour of it. It does raise questions around the current state of the “Monad of No Return” plan, but I think that’s an ongoing effort that currently calls for patience (as the majority of libraries adopt the proposed changes), and I maintain that this proposal would help that effort. Does anyone have anything further that they’d like to add? Otherwise, if no one has any objection, perhaps this proposal can be accepted at the end of the week. Thanks, Tom

2 1

Committee Review #314: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default
by Tom Harding 05 Apr '20

05 Apr '20

Friends, This proposal seems very reasonable to me, and the ramifications are minimal. Consequently, I recommend that we accept. I’d now like to open the proposal up to committee discussion. My belief is that the issue be fairly uncontentious (particularly as prior behaviour can be fully restored by explicitly passing the relevant `-Wno-...` flags to the compiler), but I welcome any thoughts either way. Thanks, Tom

5 5

merging #111: Linear Types
by Richard Eisenberg 03 Apr '20

03 Apr '20

Hi committee, On Oct 22, 2018, we conditionally accepted the linear-types proposal, which I have been shepherding. Proposal: https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… <https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li…> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/111 <https://github.com/ghc-proposals/ghc-proposals/pull/111> Conditional acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-431944…> (you may need to "load more items" many times to view this, sadly) Since the acceptance, there has been continued debate. Some of this has been about the syntax, which was left as a loose thread in the conditional acceptance. That debate has now been resolved, and the proposal reflects the final outcome of that. There is no comment declaring the new syntax accepted, but https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-519175… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-519175…> describes my recommendations, which were unopposed in the committee discussion. Recently, there has been some talk of rejecting the proposal. Considering we have already accepted the proposal, discussion of rejection seems out of scope. (Of course, anyone is free to make a separate, new proposal trying to revoke this one.) I I think it would clarify the status of this proposal if we merged the proposal text, labeling it clearly as conditionally accepted -- especially now that all remaining issues are around implementation issues, not design issues. (I'm including the specification of type inference as an implementation issue, because there is, as yet, no attempt to specify type inference beyond the implementation. It is hoped that we will rectify this, in time.) In anticipation of this, I've updated the proposal text to include the acceptance conditions. So: may we merge? I almost just did it on my own, taking rights as shepherd, but I did not want to make a unilateral move that might be seen as controversial. (Given that we have accepted the proposal, I don't think it is controversial. But then unilateralists often don't consider themselves to be controversial.) If this email gets silence, I'll likely just merge on my own early next week. Thanks! Richard

2 1

Record dot syntax: time to vote
by Simon Peyton Jones 02 Apr '20

02 Apr '20

Colleagues Now that we have agreed a set of alternatives on using dot notation for records, let's vote. We all recognise and respect that syntactic choices are a judgement call, and that reasonable people may diff in their judgements. But we need to come to as resolution and voting is a good way to do that. Please put your votes on the Google doc. I've make a section for that at the end. The document is here<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.goog…>. Just write down your preferences, in order, preferred ones first. Joachim runs an election algorithm that makes it worth specifying a total order on all options, including ones you don't like. For any you omit, you are saying "if these ones are the top contenders I have no preference between them". You can specify ties, again meaning "no preference between these". For the over-interested, the algorithm is Condorcet<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe…>; in the unlikely case that it does not produce a winner, we revert to Schultze<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipe…> Please read the document, including the Notes, carefully! We have ended up with a lot of variations, and their numbering is historical not logical. (I considered renumbering but thought that would be more confusing than helpful.) As the shepherd I am supposed to make a recommendation; it is below. Simon Shepherd's recommendations Here is my recommendation: C6 > C2b > C3 > C2a > C7 > C4 > C5 > C1 I recommend acceptance Overall, I strongly urge that we accept the proposal in some form; that is, we should not do (C1). I have been unhappy with GHC's story for records for two decades. (E.g. Lightweight extensible records for Haskell, Haskell Workshop, Paris 1999.) But the design space is so complicated that we never found something that felt "obviously right". So we did nothing drastic, and I think that was right. But there was incremental progress, sketched here<%5d(https:/gitlab.haskell.org/ghc/ghc/wikis/records/overloaded-record-fields>: * DuplicateRecordFields lets you have multiple records with the same field name. * The HasField class lets us define overloaded record selection and update functions. The proposal we are now discussing has no type-system component; it is only about syntactic sugar, allowing you to use dot-notation for field selection. (Various extensions about syntax for update were discussed, but no longer form part of the proposal; what is left is the core.) I really think this change has vastly higher impact and utility than many other accepted proposals. I know that some members of the committee differ from this view; that's fair enough. Alternatives I like: * I urge us to adopt (C6). I really really want (f M.N.x) to parse the same as (f M.n.x), where the only difference is the capitalisation of the second-last element of M.n.x. I'm leaning strongly on the connection with qualified names. We already have qualified names, and they are incredibly useful. Qualified names already treat "." specially. Moreover the proposal uses "." in precisely the same way as qualified names: a qualified name M.x allows you to pick x from the module M; this proposal allows r.x to pick a field x from a value r. I like this uniformity of both concept and syntax. * (C2b) is a weakened form of (C6) that does not allow naked selectors, thus (f .x) where there is a space before the ".". I don't see any difficulty with the postfix operator story, so I prefer (C6). But (C2b) is a little more conservative. Alternatives I actively dislike: * I urge against (C1) as I say above. * I dislike (C5) strongly, because it makes (f M.N.x) parse completely differently from (f M.n.x). The authors of the proposal say that they would withdraw the proposal outright (or at least disassociate themselves) if we adopted (C5). * I dislike (C7) for the same reason: (f M.N.x) is legal but (f M.n.x) is not. * I dislike (C4) because nothing should bind more tightly than function application. I hate that (f r .x s .y) would mean (f (r.x) (s.y)). Yes, we already have that (f r {x=2}) means (f (r {x=2})), but I think that's terrible, and we should not perpetuate it. Alternatives in the middle * (C2a) and (C3) are just like (C2b) and (C6), but additionally allow a tightly-binding record selection after a parenthesised expression. Thus (f (g x).y) means (f ((g x).y)). Allowing this is a bit tricky to specify, and the link to qualified names is much weaker. I don't think it pays its way.

10 38

Please review #314: -Wnoncanonical-mumble-instances, Shepherd: Tom Harding
by Joachim Breitner 31 Mar '20

31 Mar '20

Dear Committee, this is your secretary speaking: Enable `-Wnoncanonical-monad-instances` and `-Wnoncanonical-monoid-instances` by default has been proposed by Fumiaki Kinoshita https://github.com/ghc-proposals/ghc-proposals/pull/314 https://github.com/fumieval/ghc-proposals/blob/master/proposals/0000-warn-n… I propose Tom Harding 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/

1 0

#216: Qualified Do, recommendation: accept
by Joachim Breitner 18 Mar '20

18 Mar '20

Dear Committe, Proposal: https://github.com/tweag/ghc-proposals/blob/local-do/proposals/0000-local-d… Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/216 Summary: last June we looked at a “local do” proposal that would be a more targetted variant of RebindableSyntax, just for “do”. After an initial acceptance recommendation from me we had some good discussion, and eventually sent it back for revision. One problem, among many, was that the story around type inference wasn’t as good as with normal “do”. All attempts to give meaning to “do” via a local value (e.g. a record, or type classes etc.) were unsatisfying in one way or another. (Often something about mumble impredicative types mumble.) Anyways, Facundo Domínguez joined the author team and the discussion steered towards a less ambitious, but simpler and cleaner proposal: Qualified do. The idea is simply to treat a module qualifier on the do keyword as a qualified on all the implicit : M.do { x <- u; stmts } = (M.>>=) u (\x -> M.do { stmts }) and similar for the other monad desugaring rules. Recommendation: This seems simple, convenient and easy to understand, so I recommend accepting the proposal. Comment: There was some discussion if M.do { return x } = M.return x but it seems that changing the meaning of more than `do` it self may be more confusing than helpful, so the proposal as it stands does _not_ propose it (see Alternatives). I wish we had a better story here, and welcome ideas from the committee. WDYAT? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5