[ghc-steering-committee] GHC proposal #203: PtrRep. Recommendation: accept

Simon Peyton Jones simonpj at microsoft.com
Tue Mar 19 16:19:58 UTC 2019 

|  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 at cs.brynmawr.edu>
|  Sent: 19 March 2019 15:01
|  To: Simon Peyton Jones <simonpj at microsoft.com>
|  Cc: ghc-steering-committee at 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 at 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 at haskell.org>
|  > | On Behalf Of Joachim Breitner
|  > | Sent: 03 February 2019 14:13
|  > | To: ghc-steering-committee at 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 at 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 at 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

More information about the ghc-steering-committee mailing list