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

Richard Eisenberg rae at richarde.dev
Wed Mar 20 03:22:06 UTC 2019 

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 <ghc-steering-committee at haskell.org> 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 <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
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20190319/b8500ea2/attachment.html>

More information about the ghc-steering-committee mailing list