GitLab

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:

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.

Trac metadata

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