whats the current state of runtime rep for ghc 8 onwards?

Richard Eisenberg eir at cis.upenn.edu
Tue Apr 5 14:51:39 UTC 2016


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 <carter.schonwald at gmail.com> 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 <eir at cis.upenn.edu> 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 <carter.schonwald at gmail.com> 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
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160405/8abcbdca/attachment.html>


More information about the ghc-devs mailing list