[GHC] #8809: Prettier error messages?

[GHC]

#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