[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 bgamari):

 For the record, Richard has a student looking at error messages this
 summer; one of the later tasks on their list is the sort of rich error
 message AST described in comment:3. We discussed the design during my
 visit a few weeks ago and generally agree on this plan:

  * Decouple the choice of pretty-printer library (#14005) from the error
 message design as the former has proven to be rather tricky. Note that
 this might mean that we have to give up a little bit of the progress that
 we've made on unify our `pretty` fork with upstream, but IMHO the user-
 facing goal of improving error messages takes precedence to this internal
 engineering goal.
  * Don't introduce a type argument to the `SDoc` type; rather define it as
 it's defined today but against an annotated `Doc` type (e.g. using
 `pretty`'s annotated `Doc` instantiated at a concrete type of error
 message items:

    {{{#!hs
    type SDoc = DynFlags -> Doc GhcErrItem
    }}}
  * Start by defining only a small set of error message items. For
 instance, perhaps we start with only,
    {{{#!hs
    data GhcErrItem = SuggestLangExt [LangExt] -- ^ A suggestion to enable
 a language extension
                    | AnIdent Id               -- ^ An identifier
                    | AType Type               -- ^ A type
    }}}
    The point here is that the design of this sum should be very much
 driven by what down-stream consumers need. By starting small we avoid
 getting bogged down in these tricky design details.

 Anyways, I suspect that, if defined this narrowly, this project should be
 quite manageable and will allow us to finally make some progress on this
 goal.

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