Opened 14 months ago

Last modified 14 months ago

#9173 new bug

Better type error messages

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.8.2
Keywords: Cc: hvr
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

Generating better type-error messages is a hoary chestnut, but Herbert brought my attention to this thread on reddit, which has the following idea.

At the moment, from

module Foo where
  addThree = \x -> x + 3 :: Int
  y = addThree $ Just 5

we get this error:

Foo.hs:2:20
    Couldn't match expected type `Int' with actual type `Maybe a0'
    In the return type of a call of `Just'
    In the second argument of `($)', namely `Just 5'
    In the expression: addThree $ Just 5

Maybe we could generate this instead

Foo.hs:2:20
  inferred: "Just 5" has type "Maybe a0" 
  expected: second argument of "($)" must have type "Int"
  in the expression: addThree $ Just 5

Change History (4)

comment:1 Changed 14 months ago by thoughtpolice

I like this, and think the second set of output reads much, much better. Bonus points: use ANSI terminal colors to highlight some key words in the output, such as "Warning" or "Error" should they exist.

Lennart also makes an observation about the way the Mu Haskell compiler handles this: https://pay.reddit.com/r/haskell/comments/26tcrk/curious_with_a_bit_of_beginner_ranting_about_some/chuwwns

comment:2 Changed 14 months ago by hvr

  • Cc hvr added

comment:3 Changed 14 months ago by schyler

Here's an error that a noob making a subtle typo might get from GHC:

Prelude> map 1 [1..5]

<interactive>:2:1:
    Could not deduce (Num (a0 -> b))
      arising from the ambiguity check for ‛it’
    from the context (Num (a -> b), Num a, Enum a)
      bound by the inferred type for ‛it’:
                 (Num (a -> b), Num a, Enum a) => [b]
      at <interactive>:2:1-12
    The type variable ‛a0’ is ambiguous
    When checking that ‛it’
      has the inferred type ‛forall a b.
                             (Num (a -> b), Num a, Enum a) =>
                             [b]’
    Probable cause: the inferred type is ambiguous

I wholeheartedly agree that the information needs to be presented in a way that's easier to digest.

For what should be a really simple error, I really have to stare that down to understand what it's actually trying to say ...

Wanted: Num a => a -> b
Got: Num a => a
Last edited 14 months ago by schyler (previous) (diff)

comment:4 Changed 14 months ago by nomeata

Despite the very general ticket title, let’s not confalte multiple errors. The original ticket was a about a type mismatch (inferred vs. expected). The example by schlyer is about an ambiguous type in the GHCi prompt. Note that with some more instances added, map 1 [1..5] would type check!

Note: See TracTickets for help on using tickets.