#8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) 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 | Test Case: Blocked By: | Blocking: 13122 Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): I'd like to put aside issue of colors and technology used and focus on two things 1) the copy, the text used 2) error message structure. Personally, my list of gripes with Haskell error message text is as follows: 1. Lack of googleable error message title. 2. GHC should better quote code verbatim instead of pretty-printing AST. 3. GHC tries to name things instead of pointing me to things. I need to find them anyway to get errors fixed. 4. Location info is sometimes on the right. Therefore I'd like to propose a list of tenets for error message copy: 1. First line is a googleable (i.e. preferably not interpolated), single line stating the problem 2. GHC should point to things instead of naming them. 3. GHC should pretty-print only synthesized information (e.g. type inference generated types), otherwise it should point to code 4. Adopt MS VisualStudio standard to point to relevant information, i. e. "note:" messages. 5. GHC quotes at most 1 line of source code, cutting output at end of line. In practice, current message about type families: {{{ T10836.hs:5:5: error: Type family equations violate injectivity annotation: Foo Int = Int -- Defined at T10836.hs:5:5 Foo Bool = Int -- Defined at T10836.hs:6:5 In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} I'd like to analyze the above a bit. It has a googleable title, this is good, but the information from last two lines should be moved up. Identifier 'Foo' appears 4 times here, it is probably important. Location info is on the right, tools like editors have problems finding it and providing easy navigation, and GHC is not consistent with formatting of relevant file:line:col pointers. I'd like to propose redacting the above to (full version): {{{ T10836.hs:5:5: error: Closed type family equations violate injectivity annotation: Foo {-# PRAGMA #-} Int = Int ^~~ T10836.hs:6:5: note: other violating declaration Foo Bool = Int -- TODO: joe: remove by March ^~~ }}} And embedded (editor, non-quoting) version: {{{ T10836.hs:5:5: error: Closed type family equations violate injectivity annotation: T10836.hs:6:5: note: other violating declaration }}} Again, analysing: 1. A googleable header: yes. 2. Pointing to things instead of naming them: yes. 3. Quoting source code verbatim: yes. A to answer goldfire quesion "[This modified version] is much easier to visually process than GHC's current messages." from comment:2, from years before, this version is better because: 1. Structure of message is more rigid and enables better pattern matching by a human eye and by a navigating editor. 2. Quoting source code verbatim enables faster visual matching between error report and source code. 3. Concise title enables googling for answers. 4. Pointing to instead of naming removes a layer of indirection that needs to be followed by a human should s/he be fixing the issue in the code. Having said that I do not mind colors provided they are in predictable places (I mean, it is nice that "warning" and "error" are always pink but I would be weary introducing color mid-sentence in the message itself). I have also the feeling that my proposal "point to instead of naming" in reality requires only LINE:COL annotations in SDoc. At least I do not really see a useful annotation of any other type. While working on haskell-mode (for Emacs) I've found error spans of limited use. Indeed, given error message + pointing to first char usually is enough for a human to know if error message talks about identifier starting here or expression starting here or declaration starting here. I've done some more thinking here: https://ghc.haskell.org/trac/ghc/wiki/Proposal/ErrorMessages -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:73 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler