[Haskell-cafe] Why do we want levity polymorphism?

[David Menendez]

For context, there’s currently a big thread about the type of ($), which is going to be more complicated in GHC 8.0 due to levity/runtime rep polymorphism. As I understand it, the intention is that this more complex type will be hidden unless a levity polymorphism flag is active. From my perspective, makes the question of whether this type is too complicated for beginners moot.

What puzzles me is that I still don’t understand what this feature is *for*. According to [1], levity polymorphism is a more principled replacement for OpenKind, which was a bit of hack. Fine.

[1] https://ghc.haskell.org/trac/ghc/wiki/NoSubKinds

OpenKind exists because developers wanted to use ($), undefined, and error with unboxed types. That’s understandable, but it doesn’t seem worth all this effort. Surely, having to use error# instead of error when working with unboxed or unlifed types is a small thing next to all the other differences.

OpenKind is also used when doing type inference, because arguments to functions might be * or #. That’s more compelling, but doesn’t seem like something that needs to be exposed to the programmer.

So, is that it? Are there less-trivial levity-polymorphic functions? Is this a step on a road to new features, like [2]? Is there an article or something that makes the case for this?

[2] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes

--

Dave Menendez <da...@zednenem.com>
<http://www.eyrie.org/~zednenem/>

[Roman Cheplyaka]

On 02/10/2016 11:23 PM, David Menendez wrote:
> For context, there’s currently a big thread about the type of ($), which
> is going to be more complicated in GHC 8.0 due to levity/runtime rep
> polymorphism. As I understand it, the intention is that this more
> complex type will be hidden unless a levity polymorphism flag is active.
> From my perspective, makes the question of whether this type is too
> complicated for beginners moot.
>
> What puzzles me is that I still don’t understand what this feature is
> *for*.

> [...]

> So, is that it? Are there less-trivial levity-polymorphic functions? Is
> this a step on a road to new features, like [2]? Is there an article or
> something that makes the case for this?
>
> [2] https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes

Exactly. At least from my perspective, the value comes from unlifted
data types. Given how much doubt levity polymorphism has received
recently, I might write an article about it, but for now I recommend
watching Richard's ICFP talk https://www.youtube.com/watch?v=bDdkeKr9vVw

(Also, for those who understand Russian, we discussed levity
polymorphism in the episode 10 of the Bananas and Lenses podcast
http://bananasandlenses.net/episode010.)

Roman