- ghc-steering-committee

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 14 Feb '20

14 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

#287: Simplify subsumption , recommendation: accept
by Spiwack, Arnaud 23 Jan '20

23 Jan '20

Dear all, As the shepherd for proposal #287 [ https://github.com/ghc-proposals/ghc-proposals/pull/287 ], I recommend acceptance Summary The proposal is to remove a bunch of typing rules meant to make RankNTypes a bit more powerful (covariance and contravariance of the arrow constructor, as well as deep instantiation and deep skolemisation). The problem with these rules is that 1/ they complicate the type checker 2/ They are implemented by performing eta-expansion during elaboration, which changes the semantics of program 3/ Dropping (some of) them is beneficial for the quick-look story (proposal currently on hold). The authors have tried this change on all of Stackage, and could come up with simple fixes (~300 lines of which) for all but 2 packages (namely, singleton, because of template haskell stuff, and labels for reason not well identified). Rationale The common point of all these features is that they jiggle the position of foralls around. Which sounds reasonable at first glance. But really, they tend to interact badly with other stuff (I don't remember the circumstances, but there was a discussion of deep instantiation and deep skolemisation in the context of linear types as well). Basically, they are rather fragile features, I'd rather we did without them. I think that 300 lines of simple fixes for all of Stackage is a very small number. So it is legitimate to consider this change to have low impact. Regarding the singleton, I'm sure Richard will be happy to fix it ;-) . Only labels remains. It shouldn't be a blocker. Remaining question There is one open question on the pull request thread. Namely, how to schedule the removal. Two paths are being discussed 1. Add a `-XLessSubsumption` flag, turn it off by default, then turn it on by default in version n+1, then remove the subsumption rules altogether in version n+3 2. Simply remove the code, preferably early in the release cycle, communicate profusely. The thread participants seem to lean towards (2). The reason being that this is a change where it is easy to write code compatible with previous versions of the compiler (everything which compiles after this change also compiles before this change). Also, there is a preference for removing the relevant code sooner rather than later. But I'd like the opinion of the committee. Best, Arnaud

6 7

Please review #287: Simplify subsumption, Shepherd: Arnaud
by Joachim Breitner 14 Jan '20

14 Jan '20

Dear Committee, this is your secretary speaking: Simplify subsumption has been proposed by Simon PJ https://github.com/ghc-proposals/ghc-proposals/pull/287 https://github.com/ghc-proposals/ghc-proposals/blob/wip/spj-deep-skol/propo… I propose Arnaud Spiwak 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

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 03 Jan '20

03 Jan '20

Dear Haskell community, the GHC Steering committee is seeking nominations for one new member. The committee scrutinizes, nitpicks, improves, weights and eventually accepts or rejects proposals that extend or change the language supported by GHC and other (public-facing) aspects of GHC. Our processes are described at https://github.com/ghc-proposals/ghc-proposals which is also the GitHub repository where proposals are proposed. We are looking for a member who has the ability * to understand such language extension proposals, * to find holes and missing corner cases in the specifications, * foresee the interaction with other language features and specifications, * comment constructively and improve the proposals, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. We look for committee members who have some of these properties: * have substantial experience in writing Haskell applications or libraries, which they can use to inform judgements about the utility or otherwise of proposed features, * have made active contributions to the Haskell community, for some time, * have expertise in language design and implementation, in either Haskell or related languages, which they can share with us. The committee’s work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. We estimate the workload to be around 2 hours per week, and our process works best if members usually respond to technical emails within 1-2 weeks (within days is even better). Please keep that in mind if your email inbox is already overflowing. The GHC developers themselves are already well represented already. We seek Haskell _users_ more than GHC hackers. There is no shortage of people who are eager to get fancy new features into the language, both in the committee and the wider community. But each new feature imposes a cost, to implement, to learn, (particularly) through its unexpected interaction with other features. We need to strike a balance, one that encourages innovation (as GHC always has) while still making Haskell attractive for real-world production use and for teaching. We therefore explicitly invite “conservative” members of the community to join the committee. To make a nomination, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until January 2nd. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. We explicitly encourage self-nominations. You can nominate others, but please obtain their explicit consent to do so. (We don’t want to choose someone who turns out to be unable to serve.) On behalf of the committee, Joachim Breitner -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Records again
by Simon Peyton Jones 19 Dec '19

19 Dec '19

Dear steering committee I am keen to prevent the record-syntax debate from spiralling outwards. This has happened before, and is the main reason Haskell has remained stuck with sub-standard records for so long. So I'm playing a more active, even directive, shepherding role than usual. Vitaly, thanks for your response, but I continue to believe that we should accept some version of this proposal. I can elaborate more if needed, but I think that most of the committee agrees with the direction of travel. (But please say if you want to join Vitaly in outright rejection.) Assuming that we want to accept some version, I'd like to propose that we adopt the idea that `f r.x` means `f (r.x)`, and not the record selection `(f r).x`, nor the function composition `(f r) . x`. Joachim floated the `(f r).x` idea recently and Richard supported him. I consulted the authors who said "Interestingly, the very first version of the prototype implemented exactly that. That behaviour surprised the heck out of everyone (including you) and we were quickly and overwhelmingly convinced that it was the wrong parse and updated the proposal accordingly." I had a long conversation with Richard, who (I think) finds both alternatives acceptable. I agree strongly with the authors; I think `(f r).x` would be horrible, and would vote against such a proposal. So, in the interests of making progress, I recommend that we adopt the `f (r.x)` parse. Talking to Richard I realise that a lot depends on your starting point: 1. I regard `M.N.x` and `r.x.y` as a single token, where `.` is punctuation. Space is always significant for dot; `M . x` is quite different to `M.x`. Another example is the unbounded enumeration `[Z ..]` where you must put the space; if you write `[Z..]` you'll get the dot-operator imported from module Z. >From this point of view, Haskell's use of `(.)` as an infix operator for composition is an aberration. And parsing `f r.x` as `f (r.x)` is consistent with our parse of `f M.x`. 1. An alternative point of view is to regard `(.)` as a fully fledged operator, and all the stuff about qualified names, enumerations and so on, as a sad aberration. Under this point of view, record selection just makes the aberration worse. I realise that one reason I want the `f (r.x)` parse so strongly is my previously-implicit espousal of (A); perhaps making that explicit will help frame the conversation. I'm also very un-keen on making `r.x` illegal, which is another alternative in theory. TL;DR. Does anyone (who wants to accept the proposal in some form) seriously oppose the `f (r.x)` parse for `f r.x`? I hope that it'll be at least acceptable to everyone, and we can more on. Thanks Simon

7 13