March 2020 - ghc-steering-committee

Please review #303: Constraint based arrow notation, Shepherd: Chis Done
by Joachim Breitner 05 Jun '20

05 Jun '20

Dear Committee, this is your secretary speaking: Constraint based arrow notation has been proposed by Aleix King https://github.com/ghc-proposals/ghc-proposals/pull/303 https://github.com/lexi-lambda/ghc-proposals/blob/constraint-based-arrow-no… I propose Chris Done as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Thanks, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

5 14

Please review #285: -XNoImplicitForAll, Shepherd: Simon Marlow
by Joachim Breitner 04 May '20

04 May '20

Dear Committee, this is your secretary speaking: -XNoImplicitForAll has been proposed by John Ericson https://github.com/ghc-proposals/ghc-proposals/pull/285 https://github.com/Ericson2314/ghc-proposals/blob/no-implicit-forall/propos… I propose Simon Marlow 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 9

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

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

RecordDotSyntax proposal: next steps
by Simon Peyton Jones 17 Mar '20

17 Mar '20

Colleagues I'm sorry to have been dragging my feet on the records proposal. First there was half term holiday, and then the ICFP deadline, so I've been out of action for several weeks. It's pretty clear that we are not going to achieve 100% consensus, so the right thing to do is to vote, using the single-transferrable-vote scheme that Joachim runs. It's worth striving for consensus, because the debate can be clarifying (and has been!). But I don't regard non-consensus as a failure. These things are all judgement calls, and people's judgement can legitimately differ. Voting lets us nevertheless reach a conclusion. So here's what I propose * I've put up a list of choices for us to vote on here<https://docs.google.com/document/d/1MgovHRUUNjbuM4nM8qEe308MfbAYRh2Q8PxFHl7…>, informed by our most recent email exchanges. The first thing is to ensure that this list is * Complete: no choices that people really want are omitted. * Clear and unambiguous. When we vote we must know exactly what we are voting for! Can you all respond about that, including "Aye" if you think it is both complete and clear. * Once we are all satisfied, I'll invite you to vote. The easiest way to do so might be to edit the Google doc directly, so there's a single point of reference. Please also let me know if you think we should be doing anything else. Thanks! Simon

12 23