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@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@haskell.org>
| 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