April 2019 - ghc-steering-committee

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

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

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