February 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

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