TYPE 'UnboxedTupleRep is still a lie
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.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TYPE 'UnboxedTupleRep is still a lie","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"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.\r\n\r\nBut 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.\r\n\r\nSimon and I have cooked up a new scheme to handle this, summarized in these definitions:\r\n\r\n{{{#!hs\r\nTYPE :: RuntimeRep -> Type -- highly magical, just as before\r\ntype RuntimeRep = [UnaryRep] -- this bit is the new part\r\ndata UnaryRep = PtrRepLifted -- like the old RuntimeRep type\r\n | PtrRepUnlifted\r\n | IntRep\r\n | ...\r\ntype Lifted = '[PtrRepLifted] -- a very common case\r\ntype Type = TYPE Lifted -- good old Type\r\n}}}\r\n\r\nThe `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however.\r\n\r\nThe 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# = (# #)`.)\r\n\r\nThis 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.\r\n\r\nPatch will be written this weekend, with any luck.","type_of_failure":"OtherFailure","blocking":[]} -->
issue