[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:
                                     |  TypeErrorMessages
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 cdsmith):

 I'm summarizing a conversation with Richard in the hallway at ICFP.

 What would be nice is basically a separation of the logic to detect and
 gather information about an error from the logic to build an error
 message.  I think this can be done with a reasonable migration path.

 I'm assuming a vanilla heterogeneous typed map, of a type that I'm sure
 exists many times over in Hackage. Details here could differ, but aren't
 all that relevant.

 {{{
 #!haskell
     data TypedMap
     type TypedKey v = (String, Proxy v)
     empty :: TypedMap
     get :: TypedMap -> TypedKey v -> Maybe v
     put :: TypedKey v -> v -> TypedMap -> TypedMap
 }}}

 The key to a quick transition is to store the existing error messages (an
 `SDoc`, is that right?) alongside the map with more information. Then an
 error message is just a `(SDoc, TypedMap)`.  As a starting point, existing
 code to report errors can just use an empty map, and the initial error
 message formatting can ignore the map and just show the message.  So
 initial refactoring would have no effect.

 As a second step, one could add further stages on the formatting side that
 match a subset of errors (or even combinations of errors) and emit custom
 error messages.  To make these useful, the map would often be extended
 with extra information at the reporting site.  This would usually include
 at least some unique name or code indicating the kind of error this is,
 and optional keys that could point to expressions, types, etc.

 What this does is create a single place for logic that recognizes error
 patterns that occur frequently because of common mistakes, and does
 something smart with them.  One could imagine this being another plugin
 point, where plugins could make improvement passes to the set of errors.
 These plugins might do very non-trivial things, such as trying to reparse
 a failed module with a whole new grammar that identifies common errors.

 This is a little weaker than the naive approach of defining a gigantic
 algebraic data type of all errors, as that sounds like a maintenance
 nightmare.  It also keeps basic error messages in place so that work is
 only needed on the formatter side if and when a specific error is targeted
 for improvement.

 Just an initial thought.  It seems to be mostly independent of the choice
 of how to pretty-print the message output (e.g., embedding rich types to
 be communicated to an IDE).  This is about deciding what to say to the
 user in the first place.

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8809#comment:80>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler