<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>In the mean time, there is simply no way to do what you want. GHC 8 disallows any variable whose type has a representation that contains any type variables. Otherwise, GHC cannot be sure that the variable has a sensible runtime representation.</div><div><br></div><div>Richard</div><br><div><div>On Apr 5, 2016, at 3:55 PM, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">So in the mean time , if I want write a data type that's polymorphic over types that are heap pointer represented, I'll need to use a kind type class to bound my polymorphism? I'm interested in trying To <span></span>understand if this lets me quantify over ptry structures safely. <br><br>@ed, does any of this have an impact or relevance to your structs lib experiment you were sharing at Icfp?<br><br>On Tuesday, April 5, 2016, Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Yes, that's correct. The RuntimeRep story generally allows for such polymorphism in the future, but it's not implemented yet. One concern is that doing this would require RuntimeRep to look like</div><div><br></div><div></div><blockquote type="cite"><div>data Levity = Lifted | Unlifted</div><div>data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ...</div></blockquote><div><br></div><div>The problem here is that, in the vastly common case of kind *, this requires an extra indirection. I actually implemented this, and indeed the performance of GHC decreased. Given that we have no way, yet, to take advantage of the kind of polymorphism you seek, I flattened the structure of RuntimeRep in order to get a modest but consistent performance boost.</div><div><br></div><div>So I'm, personally, very open to this direction of travel, but we have to work out both how the polymorphism should work and how to implement this without degrading performance.</div><div><br></div><div>Richard</div><br><div><div>On Apr 5, 2016, at 2:54 AM, Carter Schonwald <<a href="javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">i was reading <a href="https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds</a><br><div>and looking at some of the applicable code, and it looks like i can't quantify over ptr-y heap values that may or may not be lifted, at least with the current state of play, is this correct?</div></div>
_______________________________________________<br>ghc-devs mailing list<br><a href="javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');" target="_blank">ghc-devs@haskell.org</a><br><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br></blockquote></div><br></div></blockquote>
</blockquote></div><br></body></html>