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

[Richard Eisenberg]

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://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst
> 
> 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-unlifted-array.rst
> 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://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 at joachim-breitner.de
> |   http://www.joachim-breitner.de/
> 
> _______________________________________________
> 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/e6fb2703/attachment.html>