- ghc-steering-committee

Re: [ghc-steering-committee] GHC proposals
by Joachim Breitner 11 Jun '19

11 Jun '19

Hi Simon, note that my cis.upenn.edu address will soon vanish with a puff; better use mail(a)joachim-breitner.de. Please allow me to respond on-list, I am sure you are not the only one who is confused by this. Yes, the relabeling was maybe the biggest mistake in our process: Proposals first have a number as Pull Request, but when they are accepted, they get a new, unrelated sequential number. We should have just re-used the PR number and have non-sequential numbers for accepted proposals. I wonder if we can still fix this. Nobody is really using the “accepted” number, so maybe it is fine? > Would it be possible to have a single list of all the proposals, with > their status? The official list of all accepted proposals is https://github.com/ghc-proposals/ghc-proposals/tree/master/proposals And the list for PRs is https://github.com/ghc-proposals/ghc-proposals/pulls where you can also filter by label, i.e. status (most links from the start page go this, with various filters applied). If someone is eager to do some hacking, one could aggregate all that in a fancy overview page somewhere (else), but I am hesitant to create such code, not because it has to be coded (that’s fun), but it has to be maintained and kept running and understood by everyone. > It would be v helpful if, for accepted proposals, the link pointed to > the canonical, final version of the proposal, and gave its canonical > final number. You mean a link “Accepted proposal” at the top of the discussion thread? Yes, that would be useful; it’s just one more bit of tedious work. Cheers, Joachim Am Dienstag, den 11.06.2019, 07:41 +0000 schrieb Simon Peyton Jones: > Joachim > I get very confused about GHC proposals and how to find the “right one”. > Here’s an example. We have > Proposal 54: Top-level kind signatures (instead of CUSKs) > Proposal 36: Top-level kind signatures > Apparently they are the same. Richard writes > When a proposal gets proposed, it is a pull request and is assigned a number. After it gets accepted, it is assigned a sequential accepted proposal number. So not-yet-decided proposals are numbered among all such proposals, and accepted proposals are numbered among all such proposals. This is perhaps confusing, but it's what we currently do. > You can get from an accepted proposal to its pull request by clicking the link at the top of the proposal. > Joachim often labels the final resting place of PRs; this one appears overlooked. I've added a link. > I don’t think I’d understood this change of numbering. So I wonder > Would it be possible to lay out the scheme on the GHC proposal home page somewhere? > Would it be possible to have a single list of all the proposals, with their status? At the moment, if you scroll around on the home page you can find various lists, but it would really help to bring them together. > Or, I suppose, two lists: one for PRs and one for accepted proposals. (In each case they may have different labels.) > It would be v helpful if, for accepted proposals, the link pointed to the canonical, final version of the proposal, and gave its canonical final number. > We have quite a lot of proposals, which you do a great job of managing. But I get a bit lost sometimes. > Thanks > Simon -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4

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

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