[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:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by goldfire):

 Replying to [comment:3 bgamari]:
 > Edsko and I were thinking about this a bit in light of the recent
 discussion on Reddit. He had what I thought was a rather nice idea: ...

 I think the idea of embedding richer info into `SDoc` is a good one. In
 particular, I like the idea that this enables a gradual transition. For
 example, we could have some large ADT defined in !TcErrors that represents
 all of the errors that the module produces (but not other modules). Then
 some of the downside of the big-ADT approach that Simon is worried about
 is reduced. And then we could do another module... and so on.

 However, I think indexing `SDoc` is going to lead to trouble. We won't be
 able to have lists of errors that originated in disparate parts of the
 compiler. And we won't be able to embed multiple types of information in
 the same error message. Instead, what if we just use dynamic typing here?
 (gasp!) By this, I mean something like

 {{{
 data Doc = forall a. Typeable a => Embed a
          | Empty
          | ...
 }}}

 When pulling out embedded bits, we just use dynamic checks to get the
 types. Although this seems somewhat un-Haskellish, I think it's forced by
 the very-dynamic nature of an error message. During parsing, a consumer
 can discover what type of embedded information should be at a certain
 spot, and then do the dynamic check. This seems like just the sort of
 thing that dynamic typing excels at.

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