<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="">OK -- yes, that all makes sense. I support acceptance.</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="">Richard</span><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 19, 2019, at 12:19 PM, 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="">| But that looks like the definition of this function will have a levity-<br class="">| polymorphic binder.<br class=""><br class="">I think not. It's a *primitive* and doesn't have definition as a Haskell function.<br class=""><br class="">At any *call* the existing restrictions will ensure that the levity of the argument is monomorphic, so we know its strictness.<br class=""><br class="">Indeed we can make personal levity-polymorphic versions of makeStableName#; but that's no worse than today.<br class=""><br class="">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. <br class=""><br class="">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). <a href="https://www.microsoft.com/en-us/research/publication/levity-polymorphism/" class="">https://www.microsoft.com/en-us/research/publication/levity-polymorphism/</a><br class=""><br class="">Simon<br class=""><br class="">| -----Original Message-----<br class="">| From: Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" class="">rae@cs.brynmawr.edu</a>><br class="">| Sent: 19 March 2019 15:01<br class="">| To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>><br class="">| Cc: <a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">| Subject: Re: [ghc-steering-committee] GHC proposal #203: PtrRep.<br class="">| Recommendation: accept<br class="">| <br class="">| I think this is an easy win -- if it works. Although there were<br class="">| opportunities to realize this before now, I'm not sure it does.<br class="">| <br class="">| The proposal mentions this new type:<br class="">| <br class="">| > makeStableName# :: forall {v :: Levity} (a :: TYPE ('PtrRep v)). a -><br class="">| > State# RealWorld -> (#State# RealWorld, StableName# a#)<br class="">| <br class="">| But that looks like the definition of this function will have a levity-<br class="">| polymorphic binder. With normal levity-polymorphic binders, we're in a real<br class="">| bind, because we don't whether to use a pointer or not. We have no such<br class="">| challenge here... but we still have a challenge: is makeStableName# strict<br class="">| in its argument or not? Maybe the answer is that every call site of<br class="">| makeStableName# has to sort this out. I suppose that would work, but it<br class="">| also means that we cannot abstract over makeStableName# -- that is, we<br class="">| won't be able to write myMakeStableName# = makeStableName# and with the<br class="">| same type.<br class="">| <br class="">| Am I barking up the wrong tree here?<br class="">| <br class="">| Thanks,<br class="">| Richard<br class="">| <br class="">| > On Mar 19, 2019, at 9:52 AM, Simon Peyton Jones via ghc-steering-<br class="">| committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>> wrote:<br class="">| ><br class="">| > Colleagues<br class="">| ><br class="">| > I propose that we accept proposal #203 on lifted-ness polymorphism.<br class="">| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith</a><br class="">| > <a href="http://ub.com" class="">ub.com</a>%2Fandrewthad%2Fghc-proposals%2Fblob%2Fpointer_rep%2Fproposals%2<br class="">| > F0000-pointer-rep.rst&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7Ca3d<br class="">| > e64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7<br class="">| > C0%7C636886044859486112&sdata=kiNFop0sQAqf%2BdvlIqXqt7foIj86%2FoYW<br class="">| > kM4nmkn0aRs%3D&reserved=0<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<br class="">| > payoff being the ability to store both lifted and unlifted values in<br class="">| > the same data types. So, for example<br class="">| ><br class="">| > data Array# :: forall (v :: Levity). TYPE ('PtrRep v) -> Type data<br class="">| > MutableArray# :: forall (v :: Levity). Type -> TYPE ('PtrRep v) -><br class="">| > Type<br class="">| ><br class="">| > This is a real win compared to having one data type for lifted and one<br class="">| for unlifted values. But they have the same *representation*: both are<br class="">| represented by a pointer.<br class="">| ><br class="">| > I believe (although the proposal does not aquite say) that the<br class="">| > proposal fully subsumes the earlier (accepted) proposal for unlifted<br class="">| > arrays<br class="">| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith</a><br class="">| > <a href="http://ub.com" class="">ub.com</a>%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fmaster%2Fproposals%2F0<br class="">| > 021-unlifted-array.rst&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7Ca3<br class="">| > de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%<br class="">| > 7C0%7C636886044859486112&sdata=AHFBdsOZK9zUHPHtL7kuyFG6PIcc5lYFdBO<br class="">| > Uew%2BMLSE%3D&reserved=0<br class="">| > So that's good!<br class="">| ><br class="">| > This proposal seems like a pretty clear win. The only downside is (as<br class="">| so often) that the full types of data types and functions gets a bit more<br class="">| complicated. But we've already accepted that with the levity polymorphism<br class="">| 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<br class="">| > | <<a href="mailto:ghc-steering-committee-bounces@haskell.org" class="">ghc-steering-committee-bounces@haskell.org</a>><br class="">| > | On Behalf Of Joachim Breitner<br class="">| > | Sent: 03 February 2019 14:13<br class="">| > | To: <a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><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="">| > | <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi</a><br class="">| > | <a href="http://thub.com" class="">thub.com</a>%2Fghc-proposals%2Fghc-proposals%2Fpull%2F203&data=02%7C<br class="">| > | 01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72<br class="">| > | f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&sdat<br class="">| > | a=m5ruL8NdOhxWIH%2BpCDvgt%2Fz%2BnEUvip39gZsNjOTN51w%3D&reserved=<br class="">| > | 0<br class="">| > | <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi</a><br class="">| > | <a href="http://thub.com" class="">thub.com</a>%2Fandrewthad%2Fghc-&data=02%7C01%7Csimonpj%40microsoft.<br class="">| > | com%7Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd01<br class="">| > | 1db47%7C1%7C0%7C636886044859486112&sdata=RZcFrrw8iROwoEVBHxou%2B<br class="">| > | D41SCZ7pHyNBSicj1vP5tw%3D&reserved=0<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="">| > | <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi</a><br class="">| > | <a href="http://thub.com" class="">thub.com</a>%2Fghc-proposals%2Fghc-proposals%23committee-process&dat<br class="">| > | a=02%7C01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7Ca3de64d79ccc4d98ebc808d6ac7bc0<br class="">| > | f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112&a<br class="">| > | mp;sdata=A5MyvZAJCtdEzs%2B65kPrjG5jihSiLH5kJ1YVCr%2B8ZV0%3D&rese<br class="">| > | rved=0 I suggest you make a recommendation, in a new e-mail thread<br class="">| > | with the proposal number in the subject, about the decision, maybe<br class="">| > | point out debatable points, and assume that anyone who stays quiet<br class="">| > | agrees with you.<br class="">| > |<br class="">| > | Thanks,<br class="">| > | Joachim<br class="">| > | --<br class="">| > | Joachim Breitner<br class="">| > | <a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a><br class="">| > |<br class="">| > | <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww" class="">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww</a><br class="">| > | .<a href="http://joachim-breitner.de" class="">joachim-breitner.de</a>%2F&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7<br class="">| > | Ca3de64d79ccc4d98ebc808d6ac7bc0f1%7C72f988bf86f141af91ab2d7cd011db47<br class="">| > | %7C1%7C0%7C636886044859486112&sdata=hQsVqHn4C8QI46PxWq1H6WGNEWpr<br class="">| > | PJVXCe4ZpxWo2zw%3D&reserved=0<br class="">| ><br class="">| > _______________________________________________<br class="">| > ghc-steering-committee mailing list<br class="">| > <a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">| > <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail" class="">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br class="">| > .<a href="http://haskell.org" class="">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&a<br class="">| > mp;data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" class="">40microsoft.com</a>%7Ca3de64d79ccc4d98ebc808d6ac<br class="">| > 7bc0f1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636886044859486112<br class="">| > &sdata=l2tcX8N2KgdEF4RskU%2BewuzdDwAd38u8odTUqYsD6ww%3D&reserv<br class="">| > ed=0<br class=""><br class="">_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></div></blockquote></div><br class=""></body></html>