Opened 13 months ago

Last modified 13 months ago

#8809 new feature request

Prettier error messages?

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


clang has very nice-looking error messages.

pretty.c:6:7: warning: incompatible pointer to integer conversion passing 'char [14]' to parameter of type 'int' [-Wint-conversion]
  foo("Hello, world!");
pretty.c:1:14: note: passing argument to parameter 'i' here
void foo(int i) {
1 warning generated.

ghc's error messages are not so good.

    Couldn't match expected type ‘()’ with actual type ‘[Char]’
    In the first argument of ‘f’, namely ‘"Hello, world!"’
    In the second argument of ‘($)’, namely ‘f "Hello, world!"’
    In the expression: print $ f "Hello, world!"

In my opinion, there are three independent improvements that could be made to GHC error messages and warnings: color, context and whitespace. Currently they're blobs of text.

Consider all three applied to error messages:

ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int'
main = print $ f "Hello, world!"

ugly.hs:3:1: note: type of 'f' is given here:
f :: () -> IO ()


ugly.hs: note: type of 'f' is inferred:
f :: forall m. Monad m => () -> m ()

In my opinion, context and whitespace are more important that color. Even without color, compare this error message to the one shown above:

ugly.hs:7:18: error: Argument to 'f' is type '[Char]' but expected 'Int'
main = print $ f "Hello, world!"

ugly.hs:3:1: note: type of 'f' is given here:
f :: () -> IO ()

In my opinion this is much easier to visually process than GHC's current messages.

Change History (2)

comment:1 Changed 13 months ago by schyler

Improving the prettiness of GHC errors is a great way to make it friendlier for people to pick up Haskell. +1

Last edited 13 months ago by schyler (previous) (diff)

comment:2 Changed 13 months ago by goldfire

I'm afraid I don't quite see what you're getting at. The original post says, "[This modified version] is much easier to visually process than GHC's current messages." My question is: Why, precisely? I don't mean to be defensive or dismissive, but trying to generate grounds for a meaningful conversation. For example, here are a few things that you might be getting at:

  • Having different colors/font weights (i.e. boldness) makes the error messages more visually interesting and therefore easier to pay attention to and read.
  • Having blank lines in the middle of single error messages makes them less imposing.
  • Using position marker in a line below some code is easier to follow than an ever-growing context.
  • In the example, the type of f is given explicitly, so the context in which the error was made is more apparent.

Short of re-engineering the entire way that GHC handles error messages, it would certainly be hard to produce exactly the output that you are requesting. But, it may be possible to address bulletpoints like my suggested ones above piecemeal and nudge ourselves in the direction of better errors.

It's also worth pointing out that each of the bulletpoints above has reasons "against", such as:

  • Not every terminal supports these extra modes. In particular, GHC has already had some trouble getting "smart" quotes working in all possible environments (or, indeed, figuring out when to fall back onto dumb quotes).
  • An automated processor of error messages (that is, an IDE built around GHC) could easily get confused around the blank lines. In fact, I believe I've run into this exact problem when running clang from emacs -- the extra "context-setting" output gets interpreted as fresh warnings.
  • It's unclear to me, personally, if having the position marker on a separate line is necessarily better than the current output.
  • The user of a DSL in Haskell is generally unaware of the full, general type of a function they are using. Perhaps including the full type in the error message would make it scarier, not friendlier.

In any case, I'm curious to hear more about the specific things GHC can do to improve. I think we all want "better" error messages, but we need to agree on a definition of "better" first. And, the changes should probably be incremental, unless we have an eager volunteer to examine the whole error-message generation mechanism holistically. There is quite a bit of code dedicated to error messages, so this is not a task to be taken on lightly!

Note: See TracTickets for help on using tickets.