Opened 2 years ago

Closed 2 years ago

#10733 closed feature request (fixed)

Improving the error message for type variable ambiguity

Reported by: Rufflewind Owned by: kanetw
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.10.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: typecheck/should_fail/tcfail133 and others
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1182
Wiki Page:

Description

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.

Change History (7)

comment:1 Changed 2 years ago by kanetw

Owner: set to kanetw

comment:2 Changed 2 years ago by goldfire

Thanks for taking this on @kanetw. The code to change should all be in TcErrors. Shout if you want advice!

comment:3 Changed 2 years ago by thomie

Differential Rev(s): Phab:D1182
Milestone: 7.12.1

comment:4 Changed 2 years ago by kanetw

Status: newpatch

comment:5 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:6 Changed 2 years ago by Austin Seipp <austin@…>

In 7b443bb1/ghc:

Improve error messages for ambiguous type variables

Improved error messages are only printed when the old message would be
"No instance for...", since they're not as helpful for "Could not deduce..."

No special test case as error messages are tested by other tests already.

Signed-off-by: David Kraeutmann <kane@kane.cx>

Reviewed By: austin, goldfire

Differential Revision: https://phabricator.haskell.org/D1182

GHC Trac Issues: #10733

comment:7 Changed 2 years ago by thomie

Resolution: fixed
Status: patchclosed
Test Case: typecheck/should_fail/tcfail133 and others
Note: See TracTickets for help on using tickets.