Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 5,251
    • Issues 5,251
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 583
    • Merge requests 583
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell CompilerGlasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #12809
Closed
Open
Issue created Nov 05, 2016 by Richard Eisenberg@raeDeveloper

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:

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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking