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.
Richard On Apr 5, 2016, at 3:55 PM, Carter Schonwald <[email protected]> wrote: > 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 understand if this lets > me quantify over ptry structures safely. > > @ed, does any of this have an impact or relevance to your structs lib > experiment you were sharing at Icfp? > > On Tuesday, April 5, 2016, Richard Eisenberg <[email protected]> wrote: > 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 > >> data Levity = Lifted | Unlifted >> data RuntimeRep = PtrRep Levity | IntRep | VoidRep | ... > > 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. > > 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. > > Richard > > On Apr 5, 2016, at 2:54 AM, Carter Schonwald <[email protected]> > wrote: > >> i was reading https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds >> 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? >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
