- ghc-steering-committee

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

Proposal #209: Levity polymorphic lift. Recommendation: accept
by Eric Seidel 17 Apr '19

17 Apr '19

Hi everyone, This proposal[1] makes the `lift` and `liftTyped` methods of the `Lift` class levity-polymorphic, which allows us to write proper `Lift` instances for unlifted types. It would also allow GHC to remove the special logic that currently supports lifting records with unlifted fields. The main downside is the potential for breakage since `lift @Foo` would now fix the RuntimeRep parameter rather than the `a`. This is unfortunate, but I doubt it will show up much. It also unfortunately requires making both `lift` and `liftTyped` methods, when we had just decided to extract `lift` from the class. I recommend accepting the proposal. Thanks! Eric [1]: https://github.com/harpocrates/ghc-proposals/blob/levity-polymorphic-lift/p…

7 19

Re: [ghc-steering-committee] GHC proposal #203: PtrRep. Recommendation: accept
by Simon Peyton Jones 17 Apr '19

17 Apr '19

| But that looks like the definition of this function will have a levity- | polymorphic binder. I think not. It's a *primitive* and doesn't have definition as a Haskell function. At any *call* the existing restrictions will ensure that the levity of the argument is monomorphic, so we know its strictness. Indeed we can make personal levity-polymorphic versions of makeStableName#; but that's no worse than today. In short, the only parts that use levity polymorphism are the primitive data types and primitive functions -- but that is still a hugely welcome benefit. Plus, as the paper showed, levity polymorphism works more often than you might expect -- that was our discovery when doing the levity polymorphism paper (Section 7). https://www.microsoft.com/en-us/research/publication/levity-polymorphism/ Simon | -----Original Message----- | From: Richard Eisenberg <rae(a)cs.brynmawr.edu> | Sent: 19 March 2019 15:01 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: ghc-steering-committee(a)haskell.org | Subject: Re: [ghc-steering-committee] GHC proposal #203: PtrRep. | Recommendation: accept | | I think this is an easy win -- if it works. Although there were | opportunities to realize this before now, I'm not sure it does. | | The proposal mentions this new type: | | > makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a -> | > State# RealWorld -> (#State# RealWorld, StableName# a#) | | But that looks like the definition of this function will have a levity- | polymorphic binder. With normal levity-polymorphic binders, we're in a real | bind, because we don't whether to use a pointer or not. We have no such | challenge here... but we still have a challenge: is makeStableName# strict | in its argument or not? Maybe the answer is that every call site of | makeStableName# has to sort this out. I suppose that would work, but it | also means that we cannot abstract over makeStableName# -- that is, we | won't be able to write myMakeStableName# = makeStableName# and with the | same type. | | Am I barking up the wrong tree here? | | Thanks, | Richard | | > On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering- | committee <ghc-steering-committee(a)haskell.org> wrote: | > | > Colleagues | > | > I propose that we accept proposal #203 on lifted-ness polymorphism. | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | > ub.com%2Fandrewthad%2Fghc-proposals%2Fblob%2Fpointer_rep%2Fproposals%2 | > F0000-pointer-rep.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Ca3d | > e64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7 | > C0%7C636886044859486112&sdata=kiNFop0sQAqf%2BdvlIqXqt7foIj86%2FoYW | > kM4nmkn0aRs%3D&reserved=0 | > | > In particular, the definition of RuntimeRep changes from | > data RuntimeRep | > = LiftedRep | > | UnliftedRep | > | IntRep | > | ... | > to | > data Levity = Lifted | Unlifted | > data RuntimeRep | > = PtrRep Levity | > | IntRep | > | ... | > | > The goal here is to support levity *polymorphism*, with the main | > payoff being the ability to store both lifted and unlifted values in | > the same data types. So, for example | > | > data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type data | > MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -> | > Type | > | > This is a real win compared to having one data type for lifted and one | for unlifted values. But they have the same *representation*: both are | represented by a pointer. | > | > I believe (although the proposal does not aquite say) that the | > proposal fully subsumes the earlier (accepted) proposal for unlifted | > arrays | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | > ub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0 | > 021-unlifted-array.rst&data=02%7C01%7Csimonpj%40microsoft.com%7Ca3 | > de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1% | > 7C0%7C636886044859486112&sdata=AHFBdsOZK9zUHPHtL7kuyFG6PIcc5lYFdBO | > Uew%2BMLSE%3D&reserved=0 | > So that's good! | > | > This proposal seems like a pretty clear win. The only downside is (as | so often) that the full types of data types and functions gets a bit more | complicated. But we've already accepted that with the levity polymorphism | stuff we already have. | > | > Silence = assent 😊 | > | > Simon | > | > | > | -----Original Message----- | > | From: ghc-steering-committee | > | <ghc-steering-committee-bounces(a)haskell.org> | > | On Behalf Of Joachim Breitner | > | Sent: 03 February 2019 14:13 | > | To: ghc-steering-committee(a)haskell.org | > | Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd: | > | Simon PJ | > | | > | Dear Committee, | > | | > | this is your secretary speaking: | > | | > | PtrRep has been proposed by Andrew Martin: | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | thub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F203&data=02%7C | > | 01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72 | > | f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&sdat | > | a=m5ruL8NdOhxWIH%2BpCDvgt%2Fz%2BnEUvip39gZsNjOTN51w%3D&reserved= | > | 0 | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | thub.com%2Fandrewthad%2Fghc-&data=02%7C01%7Csimonpj%40microsoft. | > | com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd01 | > | 1db47%7C1%7C0%7C636886044859486112&sdata=RZcFrrw8iROwoEVBHxou%2B | > | D41SCZ7pHyNBSicj1vP5tw%3D&reserved=0 | > | proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst | > | | > | I propose Simon PJ as the shepherd (he already glimpsed at it, so | > | hopefully already has an opinion.) | > | | > | Please reach consensus as described in | > | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi | > | thub.com%2Fghc-proposals%2Fghc-proposals%23committee-process&dat | > | a=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac7bc0 | > | f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&a | > | mp;sdata=A5MyvZAJCtdEzs%2B65kPrjG5jihSiLH5kJ1YVCr%2B8ZV0%3D&rese | > | rved=0 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 | > | | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww | > | .joachim-breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7 | > | Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47 | > | %7C1%7C0%7C636886044859486112&sdata=hQsVqHn4C8QI46PxWq1H6WGNEWpr | > | PJVXCe4ZpxWo2zw%3D&reserved=0 | > | > _______________________________________________ | > ghc-steering-committee mailing list | > ghc-steering-committee(a)haskell.org | > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail | > .haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a | > mp;data=02%7C01%7Csimonpj%40microsoft.com%7Ca3de64d79ccc4d98ebc808d6ac | > 7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112 | > &sdata=l2tcX8N2KgdEF4RskU%2BewuzdDwAd38u8odTUqYsD6ww%3D&reserv | > ed=0

3 2

#207: Type variables in TH quotes (recommendation: reject)
by Richard Eisenberg 17 Apr '19

17 Apr '19

Hi committee, Matthew Pickering has proposed #207: Fix the treatment of type variables in quotations. (In contrast to the email from our Most Honored and Appreciated Secretary: Matt wrote the proposal, not me.) PR: https://github.com/ghc-proposals/ghc-proposals/pull/207 <https://github.com/ghc-proposals/ghc-proposals/pull/207> Proposal: https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-c… <https://github.com/mpickering/ghc-proposals/blob/csp-types/proposals/0000-c…> The proposal considers code like this: foo :: forall a. Proxy a -> Q Exp foo _ = [| let x :: a -> a; ... |] Note that the type variable `a` is in scope in the quotation. Currently, this quotation is accepted, but then any use of it in a splice leads to an error, because the `a` has a Unique of a variable that has fallen out of scope. This is just plain wrong. Matt proposes to fix this by introducing a new class LiftT, with one method: liftTyCl :: forall {k} (a :: k). LiftT a => Q Type. This is a type-level equivalent of the existing Lift class, whose `lift` method produces a Q Exp. Instances of LiftT would be automatically provided by GHC at all types, including polytypes. Matt has already implemented the proposal. I recommend against accepting this proposal in its current form, for the following reasons: - While the proposal addresses a specific, real bug in TH, this is far from the simplest solution. Instead, we could just state that no variables brought into scope outside a TH quote remain in scope within the TH quote. The body of `foo` above would be rejected for this reason. - There is no motivation for the new feature in the proposal, other than fixing the bug. - The example in the proposal is one that, even with this proposal implemented, would not work: it uses *typed* TH, which does not allow type-level splices. So, even if Matt has a genuine need for this feature leading to the example in the proposal, implementing the proposal doesn't actually solve his problem. - The proposal mentions the possibility of using Typeable instead of LiftT, but discards this idea because we cannot solve, e.g., Typeable (forall a. a -> a); in contrast, we can solve LiftT instances of that form. However, generating a need for a LiftT instance of that form requires -XImpredicativeTypes, which is a bug, not a feature. - Although Matt has kindly already implemented this feature, we all know that the initial implementation of a feature is only the tip of the iceberg in its cost. Adding this feature, as proposed, introduces yet another class that we have to have custom treatment for, along with various other points of complexity. Perhaps with proper motivation -- and with an implementation based on Typeable -- I would be more in support. I do think this may be useful. But given the fact that the TH bug has existed since the dawn of time and no one has complained until now -- and even now, there is no practical, on the ground motivation -- I'm uninclined to move forward here. As usual, I will take silence as agreement with this recommendation to reject, but I'd love to hear opposing viewpoints. Thanks, Richard

4 3

Please review #177: Simple constrained type families, Shepherd: Vitaly
by Joachim Breitner 01 Apr '19

01 Apr '19

Dear Committee, this is your secretary speaking: Simple constrained type families has been proposed by Alex Williams https://github.com/ghc-proposals/ghc-proposals/pull/117 https://github.com/typedrat/ghc-proposals/blob/constrained-type-families/pr… 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/

2 1

#167: Deprecated Entities, rec: accept
by Vitaly Bragilevsky 20 Mar '19

20 Mar '19

Hi everyone, I was asked to shepherd the proposal #167 (Deprecated Entities, https://github.com/nineonine/ghc-proposals/blob/depr-entities/proposals/000…) It is proposed to extend (nonpositional) DEPRECATED pragma with the two specifiers to disambiguate deprecating named type-level and value-level things. In its current formulation, the proposal suggests to use the specifiers "type" for type-level things and "pattern" for value-level things as follows: data Bar = Bar {-# DEPRECATED type Bar "Don't use type Bar" #-} data Baz = Baz {-# DEPRECATED pattern Baz "Don't use data constructor Baz" #-} Using this pragma without specifiers should mean deprecating both (as is works now). After discussing this proposal within the committee (see https://mail.haskell.org/pipermail/ghc-steering-committee/2019-February/000…) I recommend acceptance with one change, namely using "data" instead of "pattern" for deprecating value-level things. Reasons for choosing "data": * it's a reserved keyword (as opposed to "value", which is another option) * we are deprecating data constructors here * it just feels right (sorry!) Reasons against "data": * it can be confusing whether we mean data type or data constructor * we use "value" and "pattern" in other places meaning basically the same thing If the committee decides to go this way, then the wider community may think about other proposals, such as * adding positional DEPRECATED pragmas (including class instances deprecation) * fixing inconsistencies with the fixity declarations ( https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-t…) and updating ExplicitNamespaces in import/export lists * deprecating usage of nonpositional DEPRECATED pragma without the specifiers Silence is understood as agreement. Regards, Vitaly

7 17

GHC proposal #203: PtrRep. Recommendation: accept
by Simon Peyton Jones 19 Mar '19

19 Mar '19

Colleagues I propose that we accept proposal #203 on lifted-ness polymorphism. https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000… In particular, the definition of RuntimeRep changes from data RuntimeRep = LiftedRep | UnliftedRep | IntRep | ... to data Levity = Lifted | Unlifted data RuntimeRep = PtrRep Levity | IntRep | ... The goal here is to support levity *polymorphism*, with the main payoff being the ability to store both lifted and unlifted values in the same data types. So, for example data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type data MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -> Type This is a real win compared to having one data type for lifted and one for unlifted values. But they have the same *representation*: both are represented by a pointer. I believe (although the proposal does not aquite say) that the proposal fully subsumes the earlier (accepted) proposal for unlifted arrays https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-u… So that's good! This proposal seems like a pretty clear win. The only downside is (as so often) that the full types of data types and functions gets a bit more complicated. But we've already accepted that with the levity polymorphism stuff we already have. Silence = assent 😊 Simon | -----Original Message----- | From: ghc-steering-committee <ghc-steering-committee-bounces(a)haskell.org> | On Behalf Of Joachim Breitner | Sent: 03 February 2019 14:13 | To: ghc-steering-committee(a)haskell.org | Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd: | Simon PJ | | Dear Committee, | | this is your secretary speaking: | | PtrRep has been proposed by Andrew Martin: | https://github.com/ghc-proposals/ghc-proposals/pull/203 | https://github.com/andrewthad/ghc- | proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst | | I propose Simon PJ 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/

2 1