- ghc-steering-committee

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

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

Please review #302: Layout and Guards in Lambda Expressions, Shepherd: Cale
by Joachim Breitner 23 Feb '20

23 Feb '20

Dear Committee, this is your secretary speaking: Layout and Guards in Lambda Expressions has been proposed by Jakob Brünker https://github.com/ghc-proposals/ghc-proposals/pull/302 https://github.com/JakobBruenker/ghc-proposals/blob/patch-1/proposals/0000-… I propose Cale Gibbard as the shepherd, so keep our new guys busy. 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

Record dot notation
by Simon Peyton Jones 13 Feb '20

13 Feb '20

Colleagues I've been slow on the records front; apologies. I think Joachim is right: we've discussed a lot of options, but in the end much of this is a judgement call with no perfect answers, and it now seems simplest to express our judgement through voting. I think we are all keen to decide this and move on. Proposal: https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot-syntax/… Lengthy discussion: https://github.com/ghc-proposals/ghc-proposals/pull/282 Here are the alternatives I propose we vote on. The first order of business is to check that they are all clear; and that I haven't omitted a worthy alternative. Here they are: 1. Reject the proposal 2. Naked .x is illegal 3. Naked .x is a postfix operator, binding exactly like application: f r .x means (f r).x 4. Naked .x is a postfix operator, binding more tightly than application: f r .x means f (r.x) Under all of (2,3,4) I think we are content that - (f r.x) means (f (r.x)) - (.x) means (\r -> r.x) By "naked .x" I mean "not preceded by an identifier (e.g. r.x), or an open paren (e.g. (.x)), or a close paren (e.g. (f 3).x) We could re-open more of this, but I'd prefer to keep it to 1-4. Let's just check everyone is happy with these alternatives. Then we can vote by putting in rank order, and Joachim can run his STV algorithm. I'm the shepherd for this proposal, so let me add my recommendations. I strongly urge that we do not adopt (1); that is, we accept the proposal in some form. 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: 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, which has a particularly high benefit/cost ratio. Now, judgements may differ about the importance of syntactic sugar -- that's why we have a committee with a diversity of views -- but I believe that dot-notation for record selection is super-important. I've wanted it for ages. Every other language has it. We have accepted other syntactic sugar with much lower utility. And the dot is already a special case, via qualified names. I respect the fact that others may differ, but I really think think this is worth it. It would be a crying shame to reject this. Unlike Chris, I don't think anything better is going to emerge, however long we wait. I am more relaxed about 2/3/4. Personally I hate (4) because I don't like *any* notation in which something binds more tightly than function application. e.g. I cordially dislike (f K {x=3}) meaning (f (K {x=3})). My preference is for (3), which allows record selection with spaces (which some argue for). But (2) represents at most a lost opportunity, not a bad thing. Thanks Simon

10 27

Please review #265: Unlifted Datatypes, Shepherd: Simon Marlow
by Joachim Breitner 30 Jan '20

30 Jan '20

Dear Committee, this is your secretary speaking: Unlifed Datatypes has been proposed by Sebastian Graf https://github.com/ghc-proposals/ghc-proposals/pull/265 https://github.com/sgraf812/ghc-proposals/blob/unlifted-data/proposals/0000… I propose Simon Marlow as the shepherd, as the expert on low-level stuff. 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/

6 11

Record syntax
by Simon Peyton Jones 28 Jan '20

28 Jan '20

Friends I'd like to move our record-syntax discussion forward. Link to proposal discussion<https://github.com/ghc-proposals/ghc-proposals/pull/282>, and December GHC steering committee debates<https://mail.haskell.org/pipermail/ghc-steering-committee/2019-December/thr…>. No-space arguments I believe have agreed that f r.x (with no spaces around the dot, and no parens around r.x) means f (r.x) That is, treat it consistently with qualified names. I asked everyone to express a view; Iavor, Eric, Arnaud, Joachim, and Richard all said it was at least acceptable; others expressed no view. So let's take that as a decision, at least for now. Naked selectors Next question: how should we treat a "naked selector", namely .x where there is no space after the dot, but there is a space before. I think there are three viable choices: 1. It's simply illegal. This defers the choice; perhaps later we will have more experience to go on. 2. It's a postfix operator, binding less tightly than function application, but more tightly than any infix operator. So then (r .x) means r.x, and (r .x .y) means r.x.y. But (f r .x) means (f r).x. This choice naturally supports chaining (nice to have, but not essential). We can write f .map double .filter isEven meaning (f.map double).filter isEven 1. It's a postfix operator, binding more tightly than function application, just as record update does. So then (f r .x) means (f r.x), and (f r .x .y s .z) means (f r.x.y s.z). This choice allows us to regard our decision about (f r.x) as what naturally happens if we parse it as three lexemes: f, r, and .x. But it also breaks the "function application binds more tightly than anything else" rule, just as (f r {x=3}) sadly does already. It does not permit chaining, at least not without stacked-up parens. In all three cases we allow (.x), meaning (\r. r.x). For (2) and (3) we can regard it as a "section", like infix operators only simpler because there is no argument. I think this is the last major question we have to answer. What are your views? Personally I lean towards (2), but I could certainly live with (1). I'm a bit reluctant to adopt (3). Simon

8 19

The GHC Committee welcomes its new members
by Joachim Breitner 24 Jan '20

24 Jan '20

Dear Haskell community, the GHC Steering committee welcomes three new members, Alejandro Serrano Mena, Cale Gibbard and Tom Harding. We are happy to see that there is continued interest in our work, and are looking forward to having fresh insights and energy on the committee. They take the seat of Sandy Maguire, who we thank for this productive work during his tenure. As you might notice, we picked more candidates than we filled slots. This is not because Sandy’s productivity need three people to fill. The idea is that there is no reason to turn away a motivated contributor just to stick to the arbitrary 10 members. Instead, we will aim at “roughly 10”, and probably not call for new members until we have dropped below that number again. On behalf of the committee, Joachim Breitner PS: Alejandro, Cale and Tom, please send me your github handles and subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de https://www.joachim-breitner.de/

1 0