#13582: Confusing error message with multiparameter type classes. -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: type-checking | errors multiparameter type classes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez):
Are you saying that GHC 7.8's error message is better because it mentions b rather than b0?
No. It is better because it gives you a clue of how to fix it: Add an instance of `First Int b Int`. In contrast: {{{ No instance for (Typeable b0) arising from a use of ‘second’ }}} gives no clue of what the problem is. How does the user infer from this that the instance `First Int b Int` is missing? Consider that: * Even if `b0` is renamed to `b`, the user stays wondering which of all the `b`s in the program it might be. The class hierarchy might have multiple levels. * Even if we understood which class is introducing the constraint, we might not know which instantiation of the other type class parameters is being attempted.
What would you LIKE it to say?
{{{ No instance for (Typeable b0) arising from a use of ‘second’ from instance 'Second Int Int' which needs missing instances 'Typeable b' and 'First Int b Int'. }}} If there are more levels in the class hierarchy, the whole path to the missing instances should be reported from the method that the user called. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13582#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler