- ghc-steering-committee

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

#195: Make Q (TExp a) into a newtype, rec: accept
by Vitaly Bragilevsky 15 Mar '19

15 Mar '19

Hi everyone, Matthew Pickering proposed to make Q (TExp a) into a newtype called Code. Proposal #195: https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948… Pull request discussion: https://github.com/ghc-proposals/ghc-proposals/pull/195 It looks like the motivation behind this proposal boils down to the convenience of writing instances which seems a good thing. The minor problem I see is the proposed name "Code" as it looks a little bit too abstract for Typed Template Haskell expressions. Nevertheless, I recommend to accept the proposal as it is. Silence is understood as agreement. Regards, Vitaly

4 4

Proposal #204: shelve for the moment
by Iavor Diatchki 13 Mar '19

13 Mar '19

Hello, I am the shepherd for #204 "Remove nested bracket restriction in Template Haskell" [1]. After some more discussion with Matt on the git-hub thread, it seems that there are some issues related to lifting values across multiple stages, so it seems better to shelve this for the moment, until those and some related TH proposals are worked out. -Iavor [1] https://github.com/ghc-proposals/ghc-proposals/pull/204

2 1

Please review #195: newtype Q (TExp a), Shepherd: Vitaly
by Joachim Breitner 07 Mar '19

07 Mar '19

Dear Committee, this is your secretary speaking: Make Q (TExp a) into a newtype has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/195 https://github.com/ghc-proposals/ghc-proposals/blob/22e97d7693edb0b3676c948… 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 #204: nested brackets, Shepherd: Iavor
by Joachim Breitner 07 Mar '19

07 Mar '19

Dear Committee, this is your secretary speaking: Remove nested bracket restriction in Template Haskell has been proposed by Matthew Pickering https://github.com/ghc-proposals/ghc-proposals/pull/204 https://github.com/ghc-proposals/ghc-proposals/blob/a5fca22bd396647c5b5efb9… 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