[GHC] #8809: Prettier error messages?

[GHC]

#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      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
  #8809,#10073,#10179                |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 For the record, some time ago I actually tried quickly prototyping the
 ideas laid out in comment:3. The branch can be found
 [[https://github.com/ghc/ghc/compare/master...bgamari:error|here]]. The
 only slightly annoying issue with the approach is that it requires adding
 an index to all mentions of `Doc`, leading to a rather difficult to rebase
 branch. That being said, I really don't think there's a whole lot of work
 here if we agree that this is the right approach. If someone was
 motivated, I'm rather confident that we could get the painful refactoring
 changes into the tree within the space of a weekend.

 Of course, the dynamically-typed alternative proposed by Richard in
 comment:9 is also still on the table. However, I suspect we'd rather want
 `Doc` to look like,
 {{{#!hs
 data Doc = forall a. (Typeable a, Outputable a) => Embed a
          | Empty
          | ...
 }}}
 to ensure that the consumer can always, at very least, output a human
 readable representation of the payload.

 It's not clear which of these options is preferrable; I'll admit that the
 dynamically-typed option feels a bit like we are trading precision and
 long-term maintainability for some temporary convenience, but perhaps this
 is too pessimistic a view.

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