Skip to content

GitLab

  • Menu
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 4,862
    • Issues 4,862
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 455
    • Merge requests 455
  • 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 Compiler
  • GHCGHC
  • Issues
  • #17569
Closed
Open
Created Dec 12, 2019 by Richard Eisenberg@raeDeveloper

Why do we have both typeRep# and typeRep?

In Data.Typeable.Internal, we see

class Typeable (a :: k) where
  typeRep# :: TypeRep a

typeRep :: Typeable a => TypeRep a
typeRep = typeRep#

Why have typeRep separate from typeRep#? The only difference I can see is the specificity of the k variable. To wit, we have

typeRep# :: forall (k :: Type) (a :: k). Typeable @k a => TypeRep @k a
typeRep :: forall {k :: Type} (a :: k). Typeable @k a => TypeRep @k a

The only difference is the braces.

But we needn't do all this. Instead, we could define

class Typeable a where
  typeRep :: TypeRep a

It's unfortunate not to make that explicitly poly-kinded, but it would be inferred to be poly-kinded, and typeRep would get the right specificity.

So, is there anything stopping us from this simplification?

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking