OK -- yes, that all makes sense. I support acceptance. Richard

On Mar 19, 2019, at 12:19 PM, Simon Peyton Jones via ghc-steering-committee wrote:

| 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 | Sent: 19 March 2019 15:01 | To: Simon Peyton Jones | Cc: ghc-steering-committee@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 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 | > | | > | On Behalf Of Joachim Breitner | > | Sent: 03 February 2019 14:13 | > | To: ghc-steering-committee@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@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@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

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee