#12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good. But there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level. Simon and I have cooked up a new scheme to handle this, summarized in these definitions: {{{#!hs TYPE :: RuntimeRep -> Type -- highly magical, just as before type RuntimeRep = [UnaryRep] -- this bit is the new part data UnaryRep = PtrRepLifted -- like the old RuntimeRep type | PtrRepUnlifted | IntRep | ... type Lifted = '[PtrRepLifted] -- a very common case type Type = TYPE Lifted -- good old Type }}} The `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however. The interpretation of this is that the kinds now include a ''list'' of unary representation forms. A "unary representation" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.) This will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature. Patch will be written this weekend, with any luck. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12809 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler