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://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-un... 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://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@joachim-breitner.de | http://www.joachim-breitner.de/

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