- ghc-steering-committee

Discussion on "Allow ScopedTypeVariables to refer to types" (#128)
by Iavor Diatchki 04 Aug '18

04 Aug '18

Hello, let's get the discussion going on proposal #128. Summary: this proposal generalizes the behavior of type variables in patterns, specifically the variables that do not refer to an explicitly quantified type parameter. The idea is that such type variables simply introduce a name for their matching type, without placing any restriction on the type. For example, consider the following definition. f (x : [a]) (y : a) = and x This would be accepted and it would have type `[Bool] -> Bool -> Bool`. This proposal is about the meaning of the type signature on `x` which states that it must be a list of something, and `a` will be a name for the type of its elements. In this case, it happens that `a` is actually just an alias for `Bool`. I am strongly in favor of this proposal. As I mentioned on the github discussion, I thought that the feature already worked as in this proposal, and was quite surprised to find out that currently, GHC has restrictions on what `a` could be, and it also complains about "multiple definitions for `a`" in the above example). Thoughts? -Iavor

5 4

Welcome Eric and Vitaly
by Joachim Breitner 02 Aug '18

02 Aug '18

Dear Committee, Eric and Vitaly, I am happy to announce that votes were received, tallied, and we have now not just one, but two new members on the committee! Welcome Eric Seidel and Vitaly Brailevsky. Eric and Vitaly will take the seats of Ryan Newton and Roman Leschinskiy. Ryan leaves immediately, while Roman will wrap up his shepherding duties. We would like to thank Ryan and Roman for their service on the committee. @Eric, Vitaly: Please subscribe to the ghc-steering-committee mailing list at https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee if you have not done so yet, and read through the process outlined at https://github.com/ghc-proposals/ghc-proposals I will reassign Ryan’s proposals for shepherding in a separate mail when I get to it. I’d also like to thank the other 3 candidates. We were very happy with all of them, and encourage you to try again next round! Thanks, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

Request for Nominations to the GHC Steering Committee
by Joachim Breitner 22 Jul '18

22 Jul '18

Dear Haskell community, the GHC Steering committee is seeking nominations for a 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 very 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 July 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 1

Please Review: Type applications in patterns (#126), Shepherd: Iavor again
by Joachim Breitner 17 Jul '18

17 Jul '18

Dear Committee, this is your secretary speaking: Type applications in patterns, by myself and with help from Richard and Simon PJ, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/126 I again propose Iavor as the shepherd. He already has #128 on his plate, and although orthogonal, both touch the same area, both are motivated and explained in more detail in the same paper, so maybe looking at both together is insightful. Iavor, please speak up if you find this is too much and would rather have this assigned to someone else. Iavor, 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/

2 1

Please Review: Allow ScopedTypeVariables to refer to types (#128), Shepherd: Iavor
by Joachim Breitner 15 Jul '18

15 Jul '18

Dear Committee, this is your secretary speaking: Allow ScopedTypeVariables to refer to types, by myself https://github.com/ghc-proposals/ghc-proposals/pull/128 I propose Iavor as the shepherd. He is just too efficient an shepherd, and the only non-chair-member without an open proposal on his plate right now. Iavor, 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/

1 0

Deprecating Exports (#134); Recommendation: accept
by Joachim Breitner 15 Jul '18

15 Jul '18

Hi, alanasp has proposed a Deprecating Exports mechanism: https://github.com/alanasp/ghc-proposals/blob/patch-2/proposals/deprecating… The gist is explained by this: module Data.List ( ... {-# DEPRECATE lines "Exported from Data.String instead" #-} , lines ...t ) where i.e. DEPRECATE pragmas in export lists cause warning when some other module uses the deprecated symbol when it is imported (only) via some deprecated export. This is a GSOC 2018 project, mentored by Matthew Pickering and Erik de Castro Lopo. The feature has a clear use-case, is self-contained and David Feuer (the containers maintainer) has already confirmed that there is a real demand for this. I suggest acceptance! As always, I will understand silence as tactic consensus. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 9

Please Review: Remove * syntax (#143), Shepherd: Ben Gamari
by Joachim Breitner 15 Jul '18

15 Jul '18

Dear Committee, this is your secretary speaking: Remove * kind syntax (#143) by Vladislav Zavialov was proposed. https://github.com/ghc-proposals/ghc-proposals/pull/143 I propose Ben Gamari as the shepherd, because he probably has the stuff paged in from shepherding #146 Ben, 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/

1 0

Replace atomicModifyMutVar# (#149), recommendation: accept
by Simon Marlow 11 Jul '18

11 Jul '18

https://github.com/ghc-proposals/ghc-proposals/pull/149 This proposal is essentially an optimisation to the atomicModifyMutVar# primitive. I won't repeat the details here, but it amounts to moving one of the thunks produced by atomicModifyMutVar# out of the primop and into the atomicModifyIORef wrapper. The advantage is that in the case of the strict version of the wrapper, atomicModifyIORef', this extra thunk is eliminated entirely, rather than being created by the primop and then immediately evaluated by the wrapper. I propose we accept the proposal to add the new primop in section 2.1, along with the straightforward additions proposed in sections 2.2 and 2.3. (the old primop will be removed, but can be defined in GHC.Exts as a wrapper around the new primop for backwards compat) However, the additions to the Data.IORef library should be considered by the libraries committee separately. (there are naming issues to be resolved in particular). Cheers Simon

4 4

Remove TypeOperators => NoStarIsType "migration" (#146); Recommendation: accept
by Ben Gamari 10 Jul '18

10 Jul '18

Hi everyone, We are being asked to consider pull request #146. This proposal is an amendment to the accepted Proposal 0020 [1], removing a migration mechanism which was found in practice to hurt more than help. Specifically, proposal 0020 currently specifies a migration period during which the -XNoStarIsType extension (which proposal 0020 introduces) will be implied by -XTypeOperators. The motivation for this was to ease the transition for packages which use * as a binary type operator. In practice it turned out that a significant number of packages are broken by this migration mechanism. Specifically, many packages use * in kind signatures while also enabling TypeOperators. The proposed amendment removes TypeOperator's implication of NoStarIsType. To be clear, this is ultimately a trade-off between optimising for users of (*) as a binary operator and users of * ~ Type. It just so happens that there are far more of the latter. Consequently, my recommendation is to accept the modified proposal. Cheers, - Ben [1] https://github.com/ghc-proposals/ghc-proposals/pull/83

5 7

Solicitation for a new member
by Joachim Breitner 10 Jul '18

10 Jul '18

Dear Committee, Ryan Newton has expressed interest in being rotated out of the committee. I spoke to the Simons, and they indicate we should ask for public nominations. Here is a draft of a mail I’d send to the usual mailing lists. Please comment. ========================== Dear community, the GHC Steering committee is seeking nomination for a new member, and ask for self-nominations. 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 in the README in 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, * make constructive comments and improvements, * judge the cost/benefit ratio and * finally come to a justifiable conclusion. Particular pluses that we look for are * candidates who have been in the community for some time, and/or * who have expertise in language design and implementation in related language, which they can share with us. The committee work requires a small, but non-trivial amount of time, especially when you are assigned a proposal for shepherding. Please keep that in mind if your email inbox is already flowing over. There is no shortage of people who are very eager to get fancy new features into the language, both in the committee and the wider community. I therefore explicitly invite “conservative” members of the community to join the committee. The GHC developers themselves are nicely represented already. Having hacked on GHC is not a requirement. To nominate yourself, please send an email to me (as the committee secretary) at mail(a)joachim-breitner.de until July 20th. I will distribute the nominations among the committee, and we will keep the nominations and our deliberations private. You cannot nominate others. But if you know of anyone else you’d think should be on the committee, please do encourage them, or talk to us and we can encourage them. On behalf of the committee, Joachim Breitner ========================== Note worth discussing: * I see no point in non-self-nominations. We can only have members that want to do this. * Do we want to encourage “conservative” members? Is that the right wording? (I see the committee a bit as a flood gate that protects against premature and not-worth-it changes. We are doing a good job of that – most of my proposals get rejected ;-) – but I think it would not hurt to explicitly keep it that way. * One could consider public nominations and deliberations, but I feel that a public discussion of who we think is the “best” is not very nice. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

6 7