- ghc-steering-committee

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

24 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

#301: Rename PtrRep to BoxedRep, recommending: accept
by Joachim Breitner 17 Dec '19

17 Dec '19

Dear Committee, this is your secretary speaking: Rename PtrRep to BoxedRep has been proposed by Neil Andrew Martin https://github.com/ghc-proposals/ghc-proposals/pull/301 I’ll shepherd that myself. It’s a simple renaming in an existing proposal, clarifying a somewhat misleading name (PtrRep) to a more precise one (BoxedRep). This looks reasonable and helpful, so I am happy to propose acceptance. Any objections? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 5

RecordDotSyntax: please express a view
by Simon Peyton Jones 16 Dec '19

16 Dec '19

Dear steering committee I'm the shepherd for the RecordDotSyntax proposal. https://github.com/ghc-proposals/ghc-proposals/pull/282 I recommend acceptance: https://github.com/ghc-proposals/ghc-proposals/pull/282#issuecomment-563477… Please reads the proposal, and as much of the discussion as you feel able, and respond in the next week or two to indicate your views. Remember: ask technical questions on the Github discussion thread, and use this mailing list for more evaluative discussion of judgement or opinion. I'd love every member of the committee to express a view. This proposal has attracted a lot of interest. Thanks Simon | -----Original Message----- | From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org> | On Behalf Of Joachim Breitner | Sent: 28 November 2019 10:11 | To: ghc-steering-committee(a)haskell.org | Subject: [EXTERNAL] [ghc-steering-committee] Please review #282: | RecordDotSyntax, Shepherd: Simon PJ | | Dear Committee, | | this is your secretary speaking: | | RecordDotSyntax language extension proposal has been proposed by Neil | Mitchell and Shayne Fletcher | https://github.com/ghc-proposals/ghc-proposals/pull/282 | https://github.com/shayne-fletcher-da/ghc-proposals/blob/record-dot- | syntax/proposals/0000-record-dot-syntax.md | | This is going to be a tricky one. It is partly about whitespace, so it | has attracted a _lot_ of community interest, by far the most so far. To | navigate that ship, I propose Simon PJ as the shepherd, because he is a | excellent moderator and community manager, and because he has the | necessary authority to hopefully get a verdict accepted. | | 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/ | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee(a)haskell.org | https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

9 23

Atze Dijkstra is ghc-proposals repo admin?
by Joachim Breitner 16 Dec '19

16 Dec '19

Hi Atze, dear committee, I noticed that Atze Dijkstra is a GitHub admin for the https://github.com/ghc-proposals/ghc-proposals repo. Is that intentional? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 3

Status
by Joachim Breitner 16 Dec '19

16 Dec '19

Dear Committee, since the last status, it seems we have become much more willing to send proposals back for revision. (BTW, you can make my life easier to always mention a status change like this on the mailing list.) Also, * Sandy Maguire stepped down, and we started a call for nominations. (I have already received two self-nominations) * we were asked to review these proposals: #177: Simple constrained type families, Shepherd: Richard #273: Local Types, Shepherd: Eric #285: -XNoImplicitForAll, Shepherd: Simon Marlow #246: Overloaded Quotations, Shepherd: Simon PJ #265: Unlifted Datatypes, Shepherd: Simon Marlow #282: RecordDotSyntax, Shepherd: Simon PJ #301: Rename PtrRep to BoxedRep, Shepherd: Joachim * we have a recommendation from the shepherd about: #195: newtype Q (Texp a) (rec: accept) #285: -XNoImplicitForAll (rec: accept) #246: Overloaded Quotations (rec: accept) #194: Updated partial type signatures (rec: accept) #293: Tweaks to #229 (rec: accept) #273: Local Types (rec: needs revision) #265: Unlifted Datatypes (rec: accept) #301: Rename PtrRep to BoxedRep (rec: accept) * we have sent the following proposals back to revision #177: Simple constrained type families #285: -XNoImplicitForAll #273: Local Types #194: Updated partial type signatures #195: newtype Q (Texp a) #274: Quick Look Impredicativity (rec: accept) * we decided about the following proposals #246: Overloaded Quotations (accept) #293: Tweaks to #229 (accept) We currently have to act on the following 2 proposals, down by one! ## Waiting for Shepherd action RecordDotSyntax language extension proposal Shepherd: Simon PJ https://github.com/ghc-proposals/ghc-proposals/pull/282 (Being a prime example of Wadler’s law, it may come to voting.) ## Waiting for committee decision Rename PtrRep to BoxedRep Shepherd: Joachim https://github.com/ghc-proposals/ghc-proposals/pull/301 Acceptance imminent. Cheers and merry Christmas to those who care about that, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 2

Precedence of r.x
by Simon Peyton Jones 13 Dec '19

13 Dec '19

A question for the committee. What does f r.x mean, where there is no white space on either side of the dot? A. The proposal says it means (f (r.x)) B. Joachim wants it to mean ((f r).x) In trying to guide the discussion to a conclusion I proposed to fix on (A). I don't think it was controversial in the public discussion, it's compatible with qualified names, and forcing `f (r.x)` looks horribly clumsy to me. Partly it's a question of whether your starting point is (a) "." is fundamentally an operator, albeit with some special extra rules, or (b) R.x, r.x, and .x are new syntactic forms, unrelated to the infix operator (.) I'm definitely thinking of it in the latter way. I don't really want to re-open this question, and I'm not sure if the authors of the proposal could live with (B). However, if the committee wants to reopen the question, then that is what we should do. Can you express a view on this narrow question? Simon

7 8

Stepping down
by Sandy Maguire 12 Dec '19

12 Dec '19

Hi all, Regrettably, I've decided to step down from the steering committee. My heart simply isn't in Haskell these days, and I'd prefer to give up my membership to someone more capable of doing good with it. For my replacement, I'd like to nominate Tom Harding and Chris Penner (both cc'd). I don't know of anyone else in the community who is as smart or dedicated as these two. Both have solid industrial credentials to help diversify the otherwise academic committee. The community at large would be very lucky to have either of them helping to steer. It's been an honour to serve with you all. Best, Sandy

5 5