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

[Carter Schonwald]

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
> <javascript:_e(%7B%7D,'cvml','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
> <javascript:_e(%7B%7D,'cvml','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/801c7325/attachment.html>