August 2018 - ghc-steering-committee

Extra Commas (#87), Recommend: accept
by Christopher Allen 05 Aug '18

05 Aug '18

https://github.com/ghc-proposals/ghc-proposals/pull/87 With the provisos mentioned by Simon starting here in mind: https://github.com/ghc-proposals/ghc-proposals/pull/87#issuecomment-3855365… I recommend we accept the proposal with the understanding that the final specification or implementation could be handled by GHC's code review process. I also have a concern about the potential interactions with TupleSections. If no objections are raised, it should be assumed that no one opposes this proposal. --- Chris Allen

7 14

Please Review: Define Kinds Without Promotion (#106), New Shepherd: Eric
by Joachim Breitner 04 Aug '18

04 Aug '18

Dear Committee, this is your secretary speaking: Define Kinds Without Promotion, by Iavor, was shepherded by Ryan, and needs to be reassigned https://github.com/ghc-proposals/ghc-proposals/pull/106 I propose Eric Seidel as the shepherd. Eric, 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: Lazy unboxed tuples (#35), New Shepherd: Vitaly
by Joachim Breitner 04 Aug '18

04 Aug '18

Dear Committee, this is your secretary speaking: Lazy unboxed tuples, by Richard, was shepherded by Ryan, and needs to be reassigned https://github.com/ghc-proposals/ghc-proposals/pull/35 I propose Vitaly Brailevsky as the shepherd. Vitaly, 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

Remove the * kind syntax (#143); Recommendation: accept
by Ben Gamari 04 Aug '18

04 Aug '18

Hi everyone, We are being asked to consider pull request #143. This proposal removes the `*` symbol as a synonym for `Type`, finishing the work started by the new `-XNoStarIsType` extension. This proposal involves a protracted but warranted transition period. In short: 1. `-XNoStarIsType` will be introduced in GHC 8.6 2. Warnings will be introduced in GHC 8.8, increasing in visibility in later releases. 3. `-XStarIsType` will be enabled by default starting 12 releases (roughly 7 years from now) after GHC 8.6. 4. 15 releases (8.5 years from now) after GHC 8.6 `-XNoStarIsType` will be removed. The reason for this breakage is that this change will have wide-spread consequences: in addition to an estimated 25% of Hackage being affected, a generation of written documentation and pedagogical material will need to be revised. While the costs of the change are high, so are the benefits. `*` is an awkward special case in GHC's syntax and is quite hard to search for. Moreover, the `StarIsType` will present a significant hurdle to the future introduction of `DependentHaskell` since `*` may then signify either term-level numeric multiplication or `Type`. For these reasons my recommendation is that we accept the proposal. Cheers, - Ben

3 4

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