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,868
    • Issues 4,868
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 456
    • Merge requests 456
  • 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
  • #10733
Closed
Open
Created Aug 04, 2015 by Rufflewind@Rufflewind

Improving the error message for type variable ambiguity

This is a summary of a discussion on ghc-devs.

The current message when a type variable is ambiguous could use a little rewording to improve its friendliness towards the user. Currently, it looks like this:

No instance for (Foldable t0) arising from a use of ‘elem’
The type variable ‘t0’ is ambiguous
Relevant bindings include valid :: t0 Char (bound at …)
Note: there are several potential instances:
  instance Foldable (Either a) -- Defined in ‘Data.Foldable’
  instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’
  instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i)
    -- Defined in ‘Data.Foldable’
  ...plus three others

The focus seems to be on "No instance", which, while technically correct, does not usually lead to the correct solution of the problem. In particular, the "type variable is ambiguous" does not appear until the 2nd or 3rd line, making it easy to miss, which may lead to confusion with other kinds of "No instance" errors that have a similar leading sentence.

There are two ways to fix this error usually:

  • By defining instance Foldable t0, but this is rarely what the user wants.
  • By fixing the ambiguity using a type annotation.

Given that the latter seems to be a more likely cause, it may help if the error message were rewritten to prioritize that, while also leaving the first solution open if the user really knows what they are doing.

Therefore, it is suggested that the message should reword in a way similar to this:

Ambiguous type variable ‘t0’ arising from a use of ‘elem’
caused by the lack of an instance ‘(Foldable t0)’
Relevant bindings include valid :: t0 Char (bound at …)
Either use a type annotation to specify what ‘t0’ should be
based on these potential instance(s):
  instance Foldable (Either a) -- Defined in ‘Data.Foldable’
  instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’
  instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i)
  ... plus three others and possibly more from other modules that
      the compiler has not yet encountered
or define the required instance ‘(Foldable t0)’

which puts the emphasis on "ambiguous type variable" in the first few words while also outlining the possible solutions for the user and reminding them of the open-world assumption.

Trac metadata
Trac field Value
Version 7.10.2
Type FeatureRequest
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