- ghc-steering-committee

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 10 May '19

10 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 08 May '19

08 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

Please review #194: Updated partial type signatures, Shepherd: Vitaly
by Joachim Breitner 04 May '19

04 May '19

Dear Committee, this is your secretary speaking: Updated partial type signatures have been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/194 https://github.com/goldfirere/ghc-proposals/blob/updated-partial-type-sigs/… I propose Vitaly 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

Please review #190: Module qualified syntax, Shepherd: Simon M
by Joachim Breitner 02 May '19

02 May '19

Dear Committee, this is your secretary speaking: Module qualified syntax has been proposed by Shayne Fletcher https://github.com/ghc-proposals/ghc-proposals/pull/190 https://github.com/shayne-fletcher-da/ghc-proposals/blob/module-qualified-s… Simon Marlow has already volunteered to 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/

8 16

[Proposal] #175: Lift.liftTyped (recommendation: accept)
by Ben Gamari 02 May '19

02 May '19

Hi everyone, I have been asked to Shepard #175, which proposes to add a `liftTyped` method to the `Lift` typeclass used to lift Haskell values into Template Haskell splices. Currently the `Lift` typeclass provides no guarantee of type-safety, even when used in a Typed Template Haskell context. The proposal resolves this limitation by adding a typed lifting operation to the `Lift` class: class Lift t where lift :: t -> Q Exp liftTyped :: t -> Q (TExp t) While this addition will break manually-written `Lift` instances, we recommended that users derive such instances for quite a while now, so it is not expected that the breakage will be wide-spread. In light of this, I recommend that we accept this proposal. Given that we will likely want to get this in to 8.8, I suggest that we limit the discussion to a week unless there is dissent. Cheers, - Ben

6 19

Unhappy proposers
by Joachim Breitner 29 Apr '19

29 Apr '19

Dear Committee, I have received an email from one of our most productive proposal writers, Matthew, who we have left quite unhappy with the process, and I hope we can take the time to see what went wrong, and what we can do differently to not be wasteful with the motivation of the Matthews out there. Matthew asked me to paraphrase his complaints, just to get this started on a productive tone. So I’ll play annoyance tone firewall. The PR in question is #207 (Fix the treatment of type variables in quotations), and he has three main reasons why he is unsatsified: 1. Delay ======== There was a long delay between consensus on the mailing list (March 7) and the official announcement on GitHub. This is clearly true, and is purely on me, and I am sorry for that. I try to do a monthly sweep of the committee activities, including closing or accepting proposals where I did not do it directly, but well, the last month turned out to be 90 days or so … I will try to be better here, but also appreciate nudges. Also, shepherds, if you detect consensus, feel encouraged to respond to the list with “Looks like we can accept/reject this, Joachim, can you do it?” Then I am likely to do the bureaucratic acts directly. 2. Lack of understanding ======================== Matthew has the impression that the itch he was trying to scratch, the overall needs of Typed Template Haskell (a still rarely used feature, but dear to his hard) and his solutions are not well understood. I am not in a position (and this is maybe not the right thread) to judge who is wrong and who is right. And maybe that is partly the point: Not the whole committee is in a position to understand the implications of a change to, say, Typed Template Haskell. Do we need to adjust our process to that somehow? How do we deal with that? Also, I think we can recognize that we should not underestimate the motivation and the actual needs of the people who sit down and write proposals, and assume good faith. Matthew says that the bug he tries to fix here does affect his actual work, and in particular that our solution (forbid type variables in splices) does not actually solve his problem. 3. Lack of communication ======================== Finally, Matthew points out that some of the reasons that led to the rejection were not properly discussed with him as the author first. I agree that this is a problematic pattern, and one that I have observed a few times too: A proposal gets proposed, the shepherd recommends rejection (or the discussion veers in that direction), we discuss the pros and cons, and then just reject it. I understand how a proposer might feel helpless in that situation. Worse, they see that proposals by committee members have an easier time, because then the committee member happens to be on the list and can defend and explain their proposal better. (This point was not raised by Matthew, but added by me). Luckily, I think this problem can be solved in a procedural way. Procedural proposal A: When a shepherd intents to proposal rejecting a proposal, he first writes his rationale on the Github discussion thread and waits for the author’s rebuttal. This can (and is encouraged) to lead to a discussion between shepherd and authors (and any further interesting party or committee member) with one of these outcomes: * the shepherd is swayed and proposes acceptance, * the proposal is improved and the shepherd can propose to accept it, * the authors withdraw the proposal, * no agreement can be reached, and the discussion comes to an end. Now the shepherd may propose rejecting to the committee. I think this process would give the authors a bigger say and role, more insight and warning into a possible rejection, and thus hopefully better satisfaction in the end. A simpler variant of that with a similar result would be something we have discussed earlier: Procedural proposal B: The committee discusses proposals on Github; the mailing list is only used for announcement (new proposal and shepherd assignment, shepherd’s recommendation, decision, status messages, metadiscussions like this one.) What are you opinions here? Matthew, would any of these procedures have given you a better experience and/or outcome? I hope we can turn Matthew’s bad experience into something with a productive outcome! (Note that I have not included all technical details of Matthew’s email here, to keep this focused on the procedural problems he points out. Matthew, maybe you can raise the good technical points on Github separately?) Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 12

Process tweak: GitHub centric way
by Joachim Breitner 26 Apr '19

26 Apr '19

Hi, after even Richard, who earlier said > Primarily, I'm worried that GitHub can be a noisy place, and if we > have our deliberations there, our status as a decision-making > committee is somewhat compromised is now willing to try a github-based process, I wrote up a concrete process teak, now at https://github.com/ghc-proposals/ghc-proposals/pull/225 (see “Files changed” for the changes). Tweaks and comments welcome, ideally on GitHub (if only to see how that goes). In a little while, unless there is clear consensus, I’ll likely do a vote on the various process variants (using ranked voting, of course, so that we put variants on the ballot). Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

1 0

Please review #213: Namespace specifiers, Shepherd: Iavor
by Joachim Breitner 18 Apr '19

18 Apr '19

Dear Committee, this is your secretary speaking: Namespace specifiers have been proposed by Richard https://github.com/ghc-proposals/ghc-proposals/pull/213 https://github.com/goldfirere/ghc-proposals/blob/namespaces/proposals/0000-… I propose Iavor 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

Please review #176: SCC Parsing, Shepherd: Simon M
by Joachim Breitner 17 Apr '19

17 Apr '19

Dear Committee, this is your secretary speaking: Meaning-preserving parsing rules for SCC annotations has been proposed by Vladislav Zavialov: https://github.com/ghc-proposals/ghc-proposals/pull/176 https://github.com/int-index/ghc-proposals/blob/scc-parsing/proposals/0000-… I propose Simon Marlow as the shepherd (he already glimpsed at it, so hopefully already has an opinion.) 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/

8 19