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,259
    • Issues 5,259
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 563
    • Merge requests 563
  • 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
  • #13324
Closed
Open
Issue created Feb 23, 2017 by Ryan Scott@RyanGlScottMaintainer

Allow PartialTypeSignatures in the instance context of a standalone deriving declaration

Currently, if you try to use a wildcard anywhere in an instance context, it will fail immediately:

$ ghci
GHCi, version 8.0.2: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> instance _ => Show (Maybe a)

<interactive>:1:10: error:
    Wildcard ‘_’ not allowed
      in an instance declaration for ‘Show’

But there's one situation where we could lift this restriction: the context of a standalone, derived instance declaration. That is, something like this:

deriving instance _ => Show (Maybe a)

Why? Because GHC already has the machinery needed to infer what the context should be (see this part of TcDerivInfer), so if a user turned on PartialTypeSignatures, GHC could just fill in the wildcard with the inferred constraints.

The implementation won't be //that// easy, however, since we'd also have to watch out for trickery such as:

deriving instance (C a, _) => C (T a b c)

I only mentioned putting wildcards in a derived instance //context//, because I think allowing the use of wildcards elsewhere in the instance head might be too difficult to deal with. I mean, how would you fill in this, for example?

instance (_ a)

This mini-feature has a very practical application: it would allow users to wield the flexibility of StandaloneDeriving without having to manually type in the instance context every time. That is, users could type in these instances:

deriving instance _ => Data (T a b c)
deriving instance _ => Eq (T a b c)

Instead of their fully spelled-out, more laborious counterparts. This would be crucial for Template Haskell, as its ability to infer these contexts is quite limited (see #10607 (closed) for an example where this cropped up).

Idle thought: could this be generalized to work for the instance context of //any// instance declaration (and not just derived ones)? From an outside perspective, it seems like typechecking other instances would require inferring constraints in a fashion quite similar to that of derived instances. But I am not at all familiar with that part of the typechecker, so I might be totally off here.

Trac metadata
Trac field Value
Version 8.0.1
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Compiler (Type checker)
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