- ghc-steering-committee

Status
by Joachim Breitner 10 Mar '21

10 Mar '21

Dear Committee, another status update, because why not. A small reminder: These mails have two sections, one that’s a delta since last status, but below is a summary of all proposals we have to act on. Please at least scroll through that on each status mail to see if you are listed, maybe you forgot something (or I made a mistake). So here’s the delta since last month. * GHC2021 defined! Yay! * Bylaws merged! Yay * Simon², Iavor, Richard and me had thus their terms expired. The Simons, as key members, wanted to continue and were voted back in. The others are now “expiring”, until the next nomination round concludes. Alejandro is going to run that process. * we were asked to review these proposals: #390: Fine-grained pragmas, Shepherd: Vitaly * we have a recommendation from the shepherd about: #368: Warn on prefix/suffix operators (accept) * we have sent the following proposals back to revision - none - * we decided about the following proposals #313: Delimited continuation primops (accept) #387: The Char kind (accept) #368: Warn on prefix/suffix operators (accept) We currently have to act on the following 5 proposals, down by 2. ## Waiting for committee decision #381: Visible 'forall' in types of terms, Shepherd: Iavor Recommendation was to reject, but discussion went into the more abstract “whither dependent Haskell”. But what does this mean for this proposal? Iavor, can you pick this up again? #369: Add sumToTag# primop, Shepherd: Eric Essentially accepted, waiting for feedback from the author on final tweaks. Eric, care to nudge the author, or just do it? #302: \of, Shepherd: Cale No new discussion yet. It seems there was some confusion, which was cleared up by Tom, and Cale said he’ll pick it up now again. ## Waiting for Shepherd action #367: Clarify primops using unboxed sums, Shepherd: Simon Marlow Simon said he’d reject it on the Github PR. Still waiting for the discussion to start on the mailing list. #390: Fine-grained pragmas, Shepherd: Vitaly Still kinda new, but a recommendation would be good soon. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

5 18

Re: [ghc-steering-committee] [ghc-proposals/ghc-proposals] Support ergonomic dependent types (#378)
by Simon Peyton Jones 09 Mar '21

09 Mar '21

(Writing to the committee rather than polluting the DT proposal thread.) We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject. This relates back to our earlier conversation about proposal properties. Eric suggested: * Backward compatibility. Does an extension *expand* the language or *change* it? In other words, does an extension strictly accept more programs than before, or can it change the meaning of existing programs, or even reject previously valid programs? * Plausible default. Do we expect the extension to eventually be on-by-default (in GHCxxxx) and effectively disappear, or will it continue to be opt-in? -XStrict or -XRebindableSyntax are examples of an extension that we want, but that are not plausible defaults. * Localised. Is an extension *contained* within a module or is it *infectious*? Does my choice of extensions when writing a module affect which extensions downstream clients must enable? (I would say most extensions are contained, e.g. you can apply a type family without enabling TypeFamilies or match on a pattern synonym without enabling PatternSynonyms. However, you cannot call a function that takes an implicit parameter without enabling ImplicitParams.) Reading our "fork-like" criterion, it seems to be saying "it's fork-like if it is not a plausible default (in the above sense), and fork-like is bad". But as -XStrict and -XRebindableSyntax show, not being a plausible default isn't necessarily bad. Do we want to revise our language in the criteria? Simon From: Eric Seidel <notifications(a)github.com> Sent: 09 March 2021 14:05 To: ghc-proposals/ghc-proposals <ghc-proposals(a)noreply.github.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; Assign <assign(a)noreply.github.com> Subject: Re: [ghc-proposals/ghc-proposals] Support ergonomic dependent types (#378) Do we have a write up of what it means to be fork-like? Or what role the fork-like property plays in our deliberations? We have a bullet "Does not create a language fork" in the review criteria<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>. I treat it like the other criteria, a fork-like proposal is a red flag, but not an automatic reject. - You are receiving this because you were assigned. Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>.

1 0

Modification to record dot syntax propsal
by Simon Peyton Jones 07 Mar '21

07 Mar '21

Friends Please see this proposal #405 to split RecordDotSyntax into two extensions<https://github.com/ghc-proposals/ghc-proposals/pull/405> It is a small modification of #282 on record dot syntax. The top comment gives links to the versions of the proposal before and after the change. The main payload is: * Instead of RecordDotSyntax, have to independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. I recommend acceptance of this proposal, but invite the committee's view on one point (the final bullet below). Here is the thinking * RecordDotSyntax is the extension that we will eventually want programmers to user. It will probably ultimately imply NoFieldSelectors. But we aren't quite ready make that choice yet. So we don't want to specify exactly what RecordDotSyntax does yet. * So we want another, less ambitious, extension to enable record-dot syntax itself, and its desugaring into getField; and similarly for record updates. * This patch to the proposal goes just a little further, by dis-aggregating into two independent extensions, OverloadedRecordDot and OverloadedRecordUpdates. * An alternative, if the committee prefers, would be to have a single extension (say, OverloadedRecords). Please express your opinion. This should not take us long. (Technical and clarification questions would be best done on the Githhub thread, as always.) Simon

7 43

Please review #402: Stable GADT constructor syntax, Shepherd: Richard
by Joachim Breitner 23 Feb '21

23 Feb '21

Dear Committe, Stable GADT constructor syntax has been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/402 https://github.com/serokell/ghc-proposals/blob/gadt-syntax/proposals/0000-g… I propose Richard 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

Please review #403: lexical structure of numbers and identifiers, Shepherd: Arnaud
by Joachim Breitner 20 Feb '21

20 Feb '21

Dear Committee, this is your secretary speaking: Cleanup lexical structure of numbers and identifiers has been proposed by Oleg Grenus https://github.com/ghc-proposals/ghc-proposals/pull/403 https://github.com/phadej/ghc-proposals/blob/cleanup-lexical-structure/prop… I propose Arnaud 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

Please review #405: Split RecordDotSyntax, Shepherd: Simon PJ
by Joachim Breitner 20 Feb '21

20 Feb '21

Dear Committe, Split RecordDotSyntax into two extensions has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/405 This is an amendment to #282, proposing to introduce separate extensions OverloadedRecordDot and OverloadedRecordUpdate instead. I’ll propose Simon PJ as the shepherd, given that he has shepherded #282. 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

Please review #369: Add sumToTag# primop, Shepherd: Eric
by Joachim Breitner 19 Feb '21

19 Feb '21

Dear Committee, this is your secretary speaking: Add sumToTag# primop has been proposed by David Feuer https://github.com/ghc-proposals/ghc-proposals/pull/369 https://github.com/treeowl/ghc-proposals/blob/sum-to-tag/proposals/0000-sum… I’ll propose Eric Seidel 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/

5 8

Request for Nominations to the GHC Steering Committee
by Alejandro Serrano Mena 14 Feb '21

14 Feb '21

Dear Haskell community, The three-year term limit of some of the GHC Steering committee members has expired. We are really grateful for the awesome work that Iavor, Richard, and Joachim have done through these years (especially the latter, who has acted as secretary.) As a result, the GHC Steering committee is seeking nominations for new members. 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 members who have 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 interim committee secretary) at trupill at gmail.com until February 28th. 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, Alejandro Serrano

1 0

Please review #390: Fine-grained pragmas, Shepherd: Vitaly
by Joachim Breitner 09 Feb '21

09 Feb '21

Dear Committee, this is your secretary speaking: Fine-grained pragmas for classes, families, and instances has been proposed by Alejandro https://github.com/ghc-proposals/ghc-proposals/pull/390 https://github.com/serras/ghc-proposals/blob/instance-pragmas/proposals/000… I’ll propose Vitaly Bragilevsky 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/

2 1

Expiring members: Simons, Iavor, Richard, Me
by Joachim Breitner 08 Feb '21

08 Feb '21

Dear committee, with the refined bylaws merged at https://github.com/ghc-proposals/ghc-proposals/blob/master/committee.rst we now have a three year term limit. Luckily I have always tracked when each of us started, at https://github.com/ghc-proposals/ghc-proposals#who-is-the-committee so it is easy to see that the following members’s terms have expired: Iavor, Richard, Simon², me The rules are slightly different for the Simons (“key members”) and the rest of us. Simons: Do you want to stay on the committee? If you say yes, the committee does a simple majority vote to confirm that. Iavor, Richard, Joachim: We three are lame ducks now: We are now “expiring members”, we are only on the committee until the end of now triggered public call for nominations. We three are eligible to re-nominate ourselves, of course. With three expiring members we are down to 7 active members (less if one of the Simons does not want to stay on). This means a call for nominations is triggered now. I think I’ll send it out on the weekend. The text of the previous was this: https://mail.haskell.org/pipermail/haskell/2019-December/025880.html Let me know if you want me to use a different text. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 11