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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Carter Schonwald
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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-2
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 <[hidden email]> 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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;carter.schonwald@gmail.com&#39;);" target="_blank">carter.schonwald@...> 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
<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;ghc-devs@haskell.org&#39;);" target="_blank">ghc-devs@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Richard Eisenberg-2
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 <[hidden email]> 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 <[hidden email]> 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 <<a href="javascript:_e(%7B%7D,'cvml','carter.schonwald@gmail.com');" target="_blank">carter.schonwald@...> 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
<a href="javascript:_e(%7B%7D,'cvml','ghc-devs@haskell.org');" target="_blank">ghc-devs@...
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs