- ghc-steering-committee

Type annotated quoters (#125) --- recommendation: accept
by Sandy Maguire 01 Aug '19

01 Aug '19

Hi all, Proposal 125 is on the topic of making quasiquoters which annotate the type of expression they produce. For example: qq :: TQuasiQuoter Int which would work when used via foo :: Int foo = [qq|| blah ||] but would be a type error (even before expanding the splice) in the context of bar :: String bar = [qq|| blah ||] I'm in favor of this proposal. It's small, a natural extension to typed expressions+quasiquoters, and solves the very real problem of statically verifying literals at compile time. The proposal is here: https://github.com/ghc-proposals/ghc-proposals/pull/125 and my recommendation is: https://github.com/ghc-proposals/ghc-proposals/pull/125#issuecomment-510612… I have recommend a syntactic change that is *not* present in the original proposal text. It seems unfair to make the proposer jump through more hoops after a year of inactivity on this proposal. As usual, silence will be considered assent! Best, Sandy

3 3

committee deliberation discussions
by Richard Eisenberg 18 Jul '19

18 Jul '19

Hi committee, A few months ago, we decided to move final proposal deliberations to GitHub, knowing that this might not work. I'd like to claim: it's not working. Here is why: * Though I've configured my mail reader to flag messages that invite the committee to deliberate (and this works), later messages in the thread are not thus flagged (and I don't know how I would do so), and so I have to remember the proposals under deliberation manually. This is error-prone. * The requests to the community to be quiet during deliberation are not working. Some participants miss that message (it can be quite far up the thread!) and then participate. Others doubtless have something to say, but refrain... and then possibly get annoyed at those who don't heed the request. * Though I haven't collected data, my guess is that there has been less involvement from the committee in these discussions than the ones we had previously. I thus propose we move deliberations back to this list. However, some good has come from all this, so I wish to further propose: * Shepherds still post to the GitHub thread before making a "reject" recommendation. Then the shepherd and the author can work out their differences. * After emailing their recommendation, shepherds post a link to the email archive of the recommendation. This makes the deliberation more transparently a public phenomenon, while still focusing our (committee members') inboxes and our attention. The shepherd may also cross-post thoughts to the GitHub trail seeking more public or author feedback, if that is warranted. Alternatively, we can set up the mailing list so that non-member posts are moderated instead of auto-rejected. The owner of the list (who is that, anyway?) could then approve posts from proposal authors. This is an annoying manual step, but I don't think it will be burdensome in practice. What do we think? I'm happy to post a diff to the process descriptor if there is support. Richard

8 9

Please review #228: Function result type signatures, Shepherd: Simon PJ
by Joachim Breitner 16 Jul '19

16 Jul '19

Dear Committee, this is your secretary speaking: Function result type signatures have been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/228 https://github.com/int-index/ghc-proposals/blob/fn-res-sig/proposals/0000-f… I propose Simon PJ as the Shepherd, for having commented on it before. Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 1

Status
by Joachim Breitner 15 Jul '19

15 Jul '19

Dear committee, looks like my intuitive Status update cadence has become two months, rather than one. Oh well. This has happened since the last status, we * have new members. Welcome Sandy and Arnaud. Also thanks to Ben and Manuel. * were asked to review these proposals: #228 Function result type signatures (Shepherd: Simon PJ) #229 Parsing of (~) etc. (Shepherd: Richard) #160 NoToplevelFieldSelectors (Shepherd: Eric) #231 Record with syntax (Shepherd: Simon M.) #232 Ambiguous Type pragma (Shepherd: Richard) #220 QualifiedImports (Shepherd: Simon M) #240 Compile with threaded RTS (Shepherd: Simon M) * have a recommendation form the shepherd about: #229 Parsing of (~) etc. (rec: accept) #160 NoToplevelFieldSelectors (rec: accept) #231 Record with syntax (rec: accept) #220 QualifiedImports (rec: reject) #232 Ambiguous Type pragma (rec: accept) #115 Provenance-Qualified Package Imports (rec: accept) * decided about the following proposals #214 Namespace specifiers (needs revision) #216 Local Do (needs revision) #87 ExtraCommas (accepted a specific variant after voting) We currently have to act on the following 10 proposals, 5 up since last stats. Please check if any needs your action, especially as a shepherd: Compile with threaded RTS Shepherd: Simon M. Status: Acceptance imminent. https://github.com/ghc-proposals/ghc-proposals/pull/240 {-# AMBIGUOUS #-} Shepherd: Richard Status: Acceptance recommended, discussion ongoing https://github.com/ghc-proposals/ghc-proposals/pull/232 Record with syntax Shepherd: Simon M. Status: Acceptance recommended, but no consensus https://github.com/ghc-proposals/ghc-proposals/pull/231 Simplified parsing of (~) and (!) Shepherd: Richard Status: Acceptance recommended, but no consensus https://github.com/ghc-proposals/ghc-proposals/pull/229 Function result type signatures Shepherd: Simon PJ Status: Acceptance imminent. https://github.com/ghc-proposals/ghc-proposals/pull/228 Qualified Imports Shepherd: Simon M. Status: Waiting for Simon to officially make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/220 Updated partial type signatures Shepherd: Vitaly Status: Waiting for Vitaly to make a recommendation. https://github.com/ghc-proposals/ghc-proposals/pull/194 NoFieldSelectors Shepherd: Eric Status: Acceptance imminent, I believe https://github.com/ghc-proposals/ghc-proposals/pull/160 Type annotated quoters Shepherd: Sandy Status: Acceptance recommended, Simon PJ discovered some nits. https://github.com/ghc-proposals/ghc-proposals/pull/125 Provenance-Qualified Package Imports Shepherd: Arnaud Status: Acceptance recommended. Mostly agreed on. https://github.com/ghc-proposals/ghc-proposals/pull/115 Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Committee discussion: #115 Provenance-Qualified Package Imports
by Spiwack, Arnaud 12 Jul '19

12 Jul '19

Dear all, As the shepherd for #115, I've made a recommendation and started the committee discussion: https://github.com/ghc-proposals/ghc-proposals/pull/115

1 0

New tasks for our new members
by Joachim Breitner 10 Jul '19

10 Jul '19

Welcome Sandy and Arnaud, (CC’ing you still, but in general I’ll assume you will subscribe to the list). First tasks, besides subscribing to the mailing list, are: 1. Read through https://github.com/ghc-proposals/ghc-proposals/ 2. There are a few proposals in the committee deliberation list. Check the Shepherd’s recommendation and see if you agree with it. Tell us if not (you may also indicate support, of course): https://github.com/ghc-proposals/ghc-proposals/pulls?q=is%3Aopen+is%3Apr+la… 3. The following proposal were shepherded by our leaving members. These have been lingering for quite a while, so I would like to re-assign them to the new members: Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Sandy, can you shepherd this (see the README for the next steps) Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Aranud, can you shepherd this (see the README for the next steps) Looks like I can’t reassign them until you accepted my invitation to join the GitHub organization. Please ping me once you have done that. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

The GHC Committee welcomes its new members
by Joachim Breitner 10 Jul '19

10 Jul '19

Dear Haskell community, the GHC Steering committee welcomes its new two members, Sandy Maguire and Arnaud Spiwack. We are happy to see that there is continued interest in our work, and are looking forward to the insights and energy that are brought to the committee by Sandy and Arnaud. They take the seats of Ben Gamari and Manuel Chakravarty. A big thanks to Ben and Manuel for their contributions to GHC and the proposal committee. In particular Ben, who created the initials draft of the proposal process. We had four nominations in total, and I would like to preserve their privacy. Since we only had two seats to fill, we had to make a pick; nevertheless I am grateful for all nominations, and encourage everyone, including those who did not make it this time, to try again next time. Neither the committee nor its process is perfect, as the way two recent proposals went show, but we are constantly trying to refine and improve. Your feedback is always welcome, either at the committee mailing list, or in private communication with the Chairs (the two Simons), me, or any other member. On behalf of the committee, Joachim Breitner PS: Sandy and Arnaud, please subscribe to the mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Status
by Joachim Breitner 09 Jul '19

09 Jul '19

Dear committee, has it really been three months since the last status? Time flies like an arrow (and fruit flies like banana). Some proposals are stalled on individual members of the committee who have become much less active recently (Manuel, Ben, partly Chris). I encourage you (and everyone else of course) to realistically assess your commitment, and – if you think that that’s in the best interest of all involved – indicate if we should start to find new members with fresh engery. Anyways, quite a few things have happened: * were asked to review these proposals: #167 Deprecated Entities (shepherd: Vitaly) #203 PtrRep (shepherd: SPJ) #176 SCC Parsing (shepherd: Simon M) #193 forall keyword (shepherd: Eric) #155 Type Vars in Lambdas (shepherd: Iavor) #209 Levity polymorphic lift (shepherd: Eric) #210 -Wredundand-minimal-methods (shepherd: me) #190 module qualified syntax (shepherd: Simon M) #207 type variables in quotations (shepherd: Richard) #195 newtype Q (shepherd: Vitaly) #204 nested brackets (shepherd: Iavor) #179 Printing of foralls (shepherd: me) #177 constrained type families (shepherd: Vitaly) * got a recommendation from shepherds about: #193 forall keyword (rec: acccept) #176 SCC Parsing (rec: accept) #210 -Wredundand-minimal-methods (rec: accept) #209 Levity polymorphic lift (rec: accept) #207 type variables in quotations (rec: reject) #167 Deprecated Entities (rec: accept) #195 newtype Q (rec: accept) #190 module qualified syntax (rec: accept) #204 nested brackets (rec: shelve) #179 Printing of foralls (rec: acccept) #203 PtrRep (rec: accept) * decided about the following proposals #158 Add setField to HasField (accept) #28 Bundling patterns with type synonyms (reject) #167 Deprecated Entities (reject) #193 forall keyword (acccept) #207 type variables in quotations (reject) #195 newtype Q (needs revision) #210 -Wredundand-minimal-methods (accept) #203 PtrRep (accept) #176 SCC Parsing (accept) We currently have to act on the following 8 proposals, up two since the last status: Levity polymorphic lift https://github.com/ghc-proposals/ghc-proposals/pull/209 Shepherd: Eric Status: To be accepted after minor tweaks by the authors Module qualified syntax https://github.com/ghc-proposals/ghc-proposals/pull/190 Shepherd: Simon M Status: To be accepted after we decide on the pragma name Tweak printing of foralls https://github.com/ghc-proposals/ghc-proposals/pull/179 Shepherd: me Status: Ongoing discussion (Iavor had questions) Simple constrained type families https://github.com/ghc-proposals/ghc-proposals/pull/177 Shepherd: Vitaly Status: Waiting for Vitaly to make a recommendation Binding type variables in lambda expressions https://github.com/ghc-proposals/ghc-proposals/pull/155 Shepherd: Iavor Status: Discussion ongoing, Iavor did not make an official recommendation Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Manuel? Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Met with some reservation. Chris, please pick this up again. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 22

Please review #240: Threaded RTS by default, Shepherd: Simon M
by Joachim Breitner 08 Jul '19

08 Jul '19

Dear Committee, this is your secretary speaking: Compile with threaded RTS by default has been proposed by Artem Pelenitsyn https://github.com/ghc-proposals/ghc-proposals/pull/240 https://github.com/ulysses4ever/ghc-proposals/blob/master/proposals/0000-th… I propose Simon M as the shepherd (yes, you just got another one last week, but you already haven an opinion about this one, so I think this is more efficient.) Please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process In particular, talk to the authors before, if you think this should be rejected, and kick off the discussion on Github, following the steps described under “Now the shepherd proposes to accept or reject the proposal” in the above link. 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 01 Jul '19

01 Jul '19

Dear Haskell community, the GHC Steering committee is seeking nominations for two or three 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 June 23th. 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 3