<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">The proposal mentions this new type:</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><blockquote type="cite" style="font-family: Menlo-Regular; font-size: 11px;" class="">makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a -> State# RealWorld -> (#State# RealWorld, StableName# a#)<br class=""></blockquote><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">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.</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Am I barking up the wrong tree here?</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Thanks,</span><br style="font-family: Menlo-Regular; font-size: 11px;" class=""><span style="font-family: Menlo-Regular; font-size: 11px;" class="">Richard</span><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Colleagues<br class=""><br class="">I propose that we accept proposal #203 on lifted-ness polymorphism.<br class=""><a href="https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst" class="">https://github.com/andrewthad/ghc-proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst</a><br class=""><br class="">In particular, the definition of RuntimeRep changes from<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>data RuntimeRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> = LiftedRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> | UnliftedRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> | IntRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> | ...<br class="">to<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>data Levity = Lifted | Unlifted<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>data RuntimeRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> = PtrRep Levity<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> | IntRep<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> | ...<br class=""><br class="">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<br class=""><br class="">data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type<br class="">data MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -> Type<br class=""><br class="">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.<br class=""><br class="">I believe (although the proposal does not aquite say) that the proposal fully subsumes the earlier (accepted) proposal for unlifted arrays<br class="">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0021-unlifted-array.rst<br class="">So that's good!<br class=""><br class="">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. <br class=""><br class="">Silence = assent 😊<br class=""><br class="">Simon<br class=""><br class=""><br class="">| -----Original Message-----<br class="">| From: ghc-steering-committee <ghc-steering-committee-bounces@haskell.org><br class="">| On Behalf Of Joachim Breitner<br class="">| Sent: 03 February 2019 14:13<br class="">| To: ghc-steering-committee@haskell.org<br class="">| Subject: [ghc-steering-committee] Please review #203: PtrRep, Shepherd:<br class="">| Simon PJ<br class="">| <br class="">| Dear Committee,<br class="">| <br class="">| this is your secretary speaking:<br class="">| <br class="">| PtrRep has been proposed by Andrew Martin:<br class="">| https://github.com/ghc-proposals/ghc-proposals/pull/203<br class="">| https://github.com/andrewthad/ghc-<br class="">| proposals/blob/pointer_rep/proposals/0000-pointer-rep.rst<br class="">| <br class="">| I propose Simon PJ as the shepherd (he already glimpsed at it, so<br class="">| hopefully already has an opinion.)<br class="">| <br class="">| Please reach consensus as described in<br class="">| https://github.com/ghc-proposals/ghc-proposals#committee-process<br class="">| I suggest you make a recommendation, in a new e-mail thread with the<br class="">| proposal number in the subject, about the decision, maybe point out<br class="">| debatable points, and assume that anyone who stays quiet agrees with<br class="">| you.<br class="">| <br class="">| Thanks,<br class="">| Joachim<br class="">| --<br class="">| Joachim Breitner<br class="">| mail@joachim-breitner.de<br class="">| http://www.joachim-breitner.de/<br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class="">ghc-steering-committee@haskell.org<br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></div></blockquote></div><br class=""></body></html>