#11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): By the way, I know the name of the extension is `TypeInType`, but might it not make more sense to have a separate `Levity` constructor for kinds? Say `* :: TYPE T`. While the values of `Int` are things like `1 :: Int`, and they are lifted and boxed, the "values" of `*` are things like `Int :: *`, and... `Int` is not really represented by anything at runtime. But if it was, it wouldn't necessarily be a lifted, boxed pointer. Maybe you want lazy evaluation on the value level, but strict evaluation on the type level, along with a totally different runtime representation for types. I don't know of any reason why you would want to abstract over specifically (regular types of kind `*` + kinds). It seems to me that in such cases it would make just as much sense to allow unboxed types as well. On the other hand, I do realize that the name `*` is a lot more convenient than writing `forall (a :: RuntimeRep). ... (TYPE a)`, and maybe that is the real issue...? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11471#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler