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
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:
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
UnaryRep type is the big sum of all possible representations, just like the
RuntimeRep of today. It drops
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.