- ghc-steering-committee

Please Review: StableName guarantee (#163), Shepherd: Simon Marlow
by Joachim Breitner 30 Aug '18

30 Aug '18

Dear Committee, this is your secretary speaking: Remove an undocumented StableName guarantee, by David Feuer, was proposed https://github.com/ghc-proposals/ghc-proposals/pull/163 I propose Simon Marlow as the shepherd. 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

Proposal #111: Linear Types
by Richard Eisenberg 29 Aug '18

29 Aug '18

I have volunteered to shepherd Proposal #111: Linear Types. The pull request is here: https://github.com/ghc-proposals/ghc-proposals/pull/111 The authors propose adding linear functions to GHC. The argument to a linear function must be used exactly once in the function body. Motivation for this feature abounds -- essentially, linear types allow for better static checking around resource allocation and deallocation. I refer you to the proposal (and published paper) for more details here. The proposal also contains multiplicity polymorphism, where a higher-order function can be polymorphic in the multiplicity of a supplied function. Datatypes are linear by default, with a long list of (in my opinion, non-obvious) rules around syntax and exceptions to those rules. Constructors have a different multiplicity when used in an expression than they do when used in a pattern, for example. The authors leave type inference as an open question and do not state how the feature would work with either view patterns or pattern synonyms. The proposal comes with a companion document detailing the changes to Core. These changes seem appropriate. The current proposal has a fair number of open questions. I've written a long comment on the GitHub trail detailing what I was uncertain of. The proposal is not currently near the level of crispness of the proposals we normally accept. For a smaller proposal, I would just send it back to the authors without really giving it to the committee. However, there has been a great deal of effort behind writing this proposal and building an implementation, and so I think it's only fair that we give some thought about the general direction being worked in here. As to the features themselves: I'm personally far from convinced. Though I see no better way to achieve the authors' goals, the feature they have proposed is full of both sharp and dark corners. If implemented, there would be regular questions cropping up as to why such-and-such is the case or why the design is the way it is. However, this is well motivated and eagerly anticipated. And I don't think we'll be able to conjure up a better design without gaining experience with the proposed design, however flawed. I thus recommend: Encouragement to continue the proposal and implementation, with an eye toward acceptance. Furthermore, if/when merged, I would like to advertise that the feature is subject to change, with no backward compatibility guarantee, for several versions. If the feature is implemented and merged, we will learn more about it and then perhaps refine it in the future. Richard

8 25

Discussion about "Type Application in Patterns" (#126)
by Iavor Diatchki 21 Aug '18

21 Aug '18

Hello, let's also start the discussion on feature request 126. The idea here is that we allow the @ notation for explicit type applications to also be used on constructors in patterns. Using @ with a constructor in a pattern has the same meaning as it does it an expression: the provided type is used to instantiate the corresponding type parameter of the constructor. If the type contains variables, those are treated in the same way as in #128, where "unbound" variables name the matching types. Here are some examples: f1 (Just @Int x) = x -- This has type `Maybe Int -> Int` f2 (Just @[a] x) = x == "c" -- `a` is an alias for `Char` f3 (SomeException @e ex) = ... -- `e` is a name for the existentially hidden exception type Overall I think that is a simple and natural extension to the way @ already works, and I propose that we accept it. Thoughts? -Iavor

6 23

Proposal: Lazy unboxed tuples / warn on unbanged strict patterns (#35); Recommendation: Reject
by Vitaly Bragilevsky 21 Aug '18

21 Aug '18

Hi, the lazy unboxed tuples proposal ( https://github.com/ghc-proposals/ghc-proposals/pull/35) was under discussion for a long period of time (more than a year and a half since submission). As a shepherd to this proposal I recommend rejection based on the following: * there is no clearly articulated motivation in favor of this proposal despite complying with the Manual; * implementing this would lead to hard-to-trace performance issues in the users code (due to move from strictness in current GHC behaviour to laziness); * it looks like the change (B) of the proposal (warn an unbanged strict patterns) meets no complains, so it is better to be resubmitted as a separate proposal; * if resubmitted separately the change (A) should elaborate on desugaring to make potential performance drawbacks clear; * it seems (maybe mistakenly) that the author has lost his interest in this proposal. Although silence is undestood as agreement, I'd be glad to receive a feedback on this recommendation. Regards, Vitaly

5 7

Status
by Joachim Breitner 17 Aug '18

17 Aug '18

Hi committee, with the new nominations out of the way, time to stop navel gazing and doing some work! Since the last status update, we * Got two new members. Yay and welcome! * were asked to review these proposals: #149 Replace atomicModifyMutVar# (Shepherd: Simon M) #143 Remove * syntax (Shepherd: Ben) #128 Allow ScopedTypeVariables refer to types (Shepherd: Iavor) #126 Type Applications in Patterns (Shepherd: Iavor) * two reviews were reassigned: #106 Define Kinds Without Promotion (New shepherd: Eric) #35 Lazy unboxed tuples (New shepherd: Vitaly) * got a recommendation from shepherds about: #112 Remove TypeOperators => NoStarIsType "migration" (rec: accept) #149 Replace atomicModifyMutVar# (rec: accept) #111 Linear Types (rec: acceptish) #143 Remove * syntax (rec: accept) #128 Allow ScopedTypeVariables refer to types (rec: accept) #126 Type Applications in Patterns (rec: accept) * decided about the following proposals #99 forall {k} (accept) #112 Remove TypeOperators => NoStarIsType "migration" (accept) #149 Replace atomicModifyMutVar# (accept) #134 Deprecating Exports (accept) #128 Allow ScopedTypeVariables refer to types (accept) #143 Remove * syntax (accept) We currently have to act on the following 11 proposals, which is two less than last round. Lets further get the backlog down! Type applications in patterns https://github.com/ghc-proposals/ghc-proposals/pull/126 Shepherd: Iavor Status: Overall positive response, acceptance likely Type annotated quoters https://github.com/ghc-proposals/ghc-proposals/pull/125 Shepherd: Manuel Status: Still waiting for recommendation. Provenance-Qualified Package Imports https://github.com/ghc-proposals/ghc-proposals/pull/115 Shepherd: Ben Status: Still waiting for recommendation. This is pretty old! Linear types https://github.com/ghc-proposals/ghc-proposals/pull/111 Shepherd: Richard Status: acceptance-ish(?) Define Kinds Without Promotion https://github.com/ghc-proposals/ghc-proposals/pull/106 Shepherd: Eric Status: Reassigned to Eric, waiting for recommendation. ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some reservation. Visible dependent quantification (TL;DR: forall k -> k -> *) https://github.com/ghc-proposals/ghc-proposals/pull/81 Shepherd: Roman Leshchinskiy Status: Discussion needs to happen Top-level kinds signatures https://github.com/ghc-proposals/ghc-proposals/pull/54 Shepherd: Roman Leshchinskiy Status: Waiting for recommendation. Or-Patterns https://github.com/ghc-proposals/ghc-proposals/pull/43 Shepherd: Manuel Recommendation: accept Status: Round 2 discussion ebbed down Lazy unboxed tuples https://github.com/ghc-proposals/ghc-proposals/pull/35 Shepherd: Vitaly Status: Reassigned to Vitaly, waiting for recommendation. Bundling patterns with synonyms https://github.com/ghc-proposals/ghc-proposals/pull/28 Shepherd: Chris Recommendation: accept Status: Ongoing discussion, met with some resistance. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

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

06 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 05 Aug '18

05 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 05 Aug '18

05 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