#8809: Prettier error messages? -------------------------------------+------------------------------------ Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (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! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler