May 2019 - ghc-steering-committee

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 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

Discussion on #214, Namespace specifiers
by Iavor Diatchki 17 Jun '19

17 Jun '19

Hello, let's have a discussion about proposal #214, Namespace specifiers. https://github.com/ghc-proposals/ghc-proposals/pull/214 I believe our new process is to have the discussion on Github, so please share your thoughts over there. I am a bit unclear about the steps in the new process (even though I voted for it :-), but as the shepherd I think I am supposed to make an initial? recommendation. If so, at the moment I am leaning towards a "reject": I do think that the proposal has identified a valid area for improvement, but I don't quite like the currently proposed solution---I wrote some comments on GIthub as to why. Obviously, that's just my opinion, and the discussion would benefit from more input from the committee. Cheers, -Iavor

2 2

Status
by Joachim Breitner 11 Jun '19

11 Jun '19

Dear committee, let’s see what happened in the last months. I still wonder if we should do another call for new members, to get fresh momentum here. Simons, as Chairs, what do you think? This has happened since the last status: * Triggered by input from Matthew Pickering, we refined our proposal; discussions are now supposed to be happening on GitHub and shepherd talk to authors before proposing to reject. The mail I just sent had an incomplete list of proposals that I relabeled “Pending shepherd recommendation”. See below for the full list. Dear shepherd (Iavor, Vitaly, Ben, Manuel), please follow the new process for the open proposals listed below. * were asked to review these proposals: #213 Namespace specifiers (Shepherd: Iavor) #194 Updated partial type signatures (Shepherd: Vitaly) * got a recommendation from shepherds about: - none - * returned for revision by shepherd #177 Simple constrained type families * decided about the following proposals #209 Levity-polymorphic Lift (accept) #179 Printing of foralls (accept) #190 Module qualified syntax (accept) #155 Ty vars in lambdas (accept) We currently have to act on the following 5 proposals, 3 down since last stats: Namespace Specifiers https://github.com/ghc-proposals/ghc-proposals/pull/214 Shepherd: Iavor Status: Waiting for Iavor to make a recommendation. Updated partial type signatures https://github.com/ghc-proposals/ghc-proposals/pull/194 Shepherd: Vitaly Status: Waiting for Vitaly to make a 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. Ben, this is pretty old! ExtraCommas https://github.com/ghc-proposals/ghc-proposals/pull/87 Shepherd: Chris Recommendation: accept Status: More discussion happened, no clear consensus emerging. Maybe we should just do do a vote (with fine-grained ranked options)? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

4 8

Please discuss: new lexing for (~) and (!), #229
by Richard Eisenberg 31 May '19

31 May '19

Hi all, I have started committee discussion on #229 by recommending acceptance. Please see https://github.com/ghc-proposals/ghc-proposals/pull/229#issuecomment-497811… <https://github.com/ghc-proposals/ghc-proposals/pull/229#issuecomment-497811…> Thanks, Richard

1 0

Please review #229: Parsing of (~) and (!), Shepherd: Richard
by Joachim Breitner 29 May '19

29 May '19

Dear Committee, this is your secretary speaking: Simplify parsing of (~) and (!) have been proposed by Vladislav Zavialov https://github.com/ghc-proposals/ghc-proposals/pull/229 https://github.com/int-index/ghc-proposals/blob/whitespace-bang-patterns/pr… I propose Richard as the Shepherd, has he already has groomed the proposal. 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

new process on GitHub
by Richard Eisenberg 22 May '19

22 May '19

Hi Joachim, Might I make a small suggestion: for the next 3 (arbitrary number) times a committee comes up for discussion on GitHub, could you send an email to the list, in addition to the other steps taken? This would help make sure that no proposal gets lost while we work out any notification bugs. Committee members should, ideally, be aware of the proposal discussion without this email, but it's good to be doubly sure. Thanks! Richard

2 1

Procedural change vote
by Joachim Breitner 20 May '19

20 May '19

Dear committee, quick recap: one of our valued proposal writers, Matthew, expressed unhappiness about our discussion proposal, with two important (but not the only complains) issues the inability to react to a looming rejection, and general bad insight into the discussion. Based on that feedback (thanks again, Matt!) we discussed various options. Discussion has ebbed down, and because it affects our policies, I’d like to hold a formal vote. There are three possible changes to consider, plus the option of doing nothing. The options are A. All discussion on GitHub. Our process essentially stays the same, but all discussion happens on GitHub. The mailing list is used only for status messages (new proposal, new recommendation, result, regular summary messages). During the deliberation phase, we will ask bystanders (non-members, non-authors) to refrain from making the discussion noisy. Pros: Best visibility. Easy to get feedback from authors. No fragmented discussion places. Cons: Less separation of discussion, less of a “protected space” for us”, possibly more noise, can’t technically enforce that nobody else comments B. Shepherd discussion looming rejection with the authors first. This keeps the discussion on the mailing list, but the shepherd, before recommending to reject a proposal, needs to _first_ lay out their reasons on GitHub, wait for the authors to rebut, and possibly discusses with them. I spelled out possible wording of this already on https://github.com/ghc-proposals/ghc-proposals/pull/221 Pros: Authors are taken more serious, have a say, while keeping our discussion separate Cons: More work for shepherd. Incentives are set to lean towards just recommending acceptance. Authors don't get to rebut if shepherd wants to accept, but then the committee leans towards rejection. AB. The combination of the two above I.e. author rebuttal before shepherd recommends rejection but then _also_ the committee discussion on GitHub Also spelled out already on https://github.com/ghc-proposals/ghc-proposals/pull/225 0. Do nothing. Please vote by responding to this thread with a linear ordering of your preferences. For example, my vote is AB > B > A > 0 Please cast a vote until Sunday May 5th. You can change your vote any time until voting is concluded. Voting will be concluded when no votes have been cast, but not before Sunday May 5th. We will accept the option that is preferred over any other option by a majority of the votes. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

9 15

Discussion on #155 Type Variable in Labmdas
by Iavor Diatchki 09 May '19

09 May '19

Hello, let's get the discussion going about proposal #155 ( https://github.com/goldfirere/ghc-proposals/blob/type-lambda/proposals/0000… ). Summary: the idea is pretty simple: allow functions to name their type arguments explicitly, so that they can be used in type signatures within the function's definition. The notation for a type argument is `@a`, and such type arguments can be used only when functions have an explicit type signature (technically, when GHC is doing "checking" rather then "inference"). This proposal provides an alternative to "ScopedTypeVariables" to refer to type parameters, which I think is a step in the right direction, as using the `forall` to introduce type variables always felt a bit hacky to me (now, there's a technical argument :) I am a bit concerned with the notation though: in other places where we use `@a`, (e.g., #126 type application in patterns, and TypeApplications) the `a` is a type, while in this use it must be a variable. I wonder if this punning might be confusing. I don't really have an alternative suggestion though. What does everyone else thing? -Iavor

7 26

Linear types design decisions
by Richard Eisenberg 07 May '19

07 May '19

Hi committee, As the shepherd for the Linear Types proposal (https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… <https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li…>), I've been asked to forward a few design decisions to this committee. These are outlined in https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476276… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-476276…>, but this email is meant to be mostly self-contained on the issues to consider. We have three main issues before us. I describe the issues first, and then make recommendations separately. 1. The concrete syntax for linear types. The current proposal is: - `arg # mult -> res` for arrow types. That is, `... # ... -> ...` essentially becomes a ternary operator in the language. There is a proposed BNF of this syntax at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… <https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li…>, but as of this writing, that BNF is, I believe, ambiguous for an input like `Int # Omega -> Int -> Int`, where the first arrow might or might not be part of the multiplicity. We clearly want "not", but the BNF does not currently reflect that. I am asking for Arnaud to take another stab. There is no treatment that I see of what to do if an upstream module declares a type operator named (#), but that shouldn't be hard to resolve, either by using prefix notation (#) or a qualified name Int Foo.# Bool. - `field # mult :: ty` for record field declarations and `pat # mult :: ty` for pattern bindings. This reverses the previous order. Also, because the `:: ty` is optional for a pattern binding, there is a potential ambiguity there, too, for `x # One = blah`: is that a pattern binding for x or a function binding for the term-level (#)? Presumably, the latter, and perhaps the former should require parentheses. (But note that `x :: Int = 5` is allowed today, without parens.) - The abbreviation #-> (one lexeme) for `# One ->`. I suppose this could just be an ordinary type-level operator exported from some module, but the proposal does not address this point. (Indeed, the proposal does not really propose this abbreviation -- only the commentary does. But we have been asked to decide on how to update the proposal.) - NB: The proposal introduces FUN :: Multiplicity -> forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 for the full raw function type. Some alternatives are at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… 2. How to update Template Haskell. - Should ArrowT be updated somehow? Or should we have a new MulArrowT (that presumably takes three arguments), leaving ArrowT alone? - What happens when we reify a constructor? TH's Info type contains `DataConI Name Type ParentName`, which is returned when reifying a constructor. Recall that, with linear types, constructors are multiplicity-polymorphic. Should that be reflected in the Type in the DataConI? Or do we keep things simpler? Does it depend on whether -XLinearTypes is on? - What happens when we reify a function? If the function is, say, multiplicity-polymorphic and we reify it in a module without -XLinearTypes, what do we see? Do we see the multiplicity polymorphism? 3. What to name the unrestricted multiplicity. Is it Omega or Many? -------------------- Recommendations: 1. I recommend accepting the new syntax (provided we can sort out the BNF). I don't think I can top the argument in favor of this syntax at https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437512… <https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-437512…> so I won't try. 2. - I would leave ArrowT as-is and introduce a new three-paramater MulArrowT in TH's Type datatype. ArrowT is heavily used in TH code, and it seems willfully destructive to change it. TH's syntax is already not-orthogonal in countless ways, and I think this is a fine time to add another. - I recommend that the behavior of reification be independent of what extensions are enabled. Otherwise, the possibilities for confusion and mistakes abound. - The subtleties of constructor types are described at https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li… <https://github.com/tweag/ghc-proposals/blob/linear-types2/proposals/0000-li…> If I understand this correctly, this section means that constructors cannot be classified by normal Haskell types any more, but instead need some other descriptor. The best route forward, then, is to update DataConI to be able to describe data constructors correctly, perhaps by using TH's `Con` type. This would be a breaking change, but it seems worthwhile. - Functions should be reified with their multiplicities intact. It's unclear how much the change in reification would break existing code. I recommend that, once this is implemented, we run smoke tests (compiling all of Stackage is a good way to do this) to determine the extent of the breakage. If things are bad, we can reconsider. 3. Many. It's very easy for us pointy-headed types to use fancy Greek things that look, well, Greek to everyone else. `Many` is potentially misleading is that something used `Many` times might actually be used 0 times. `Unrestricted` is really a mouthful though, and I don't think it will be hard for users to internalize that `Many` just means an undetermined amount. Let me know your thoughts on these points. As usual, silence will be taken to mean that you agree with my recommendations. Thanks, Richard

3 2