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

 Putting aside the specific proposal made in this ticket, it seems like
 generally what we need is a more semantically-rich representation for our
 error messages. This need not be a giant AST encoding every possible error
 that might arise. Our current approach of encoding messages in `SDoc`
 works fairly well. What it lacks is the ability to denote meaningful
 references to various parts of the program (e.g. types, expressions,
 constraints).

 A moderately painless(?) way to fix this would be to index `Doc` (and
 `SDoc`) on a type which could then be embedded in the document. To put it
 concretely,
 {{{#!hs
 data Doc a = Embed a
            | Empty
            | NilAbove Doc
            .
            .
            .
 }}}

 The `Embed` constructor could then be used to embed various compiler-phase
 specific atoms into the document. For instance, the type-checker might
 emit errors in the form of `SDoc TcDoc` where,
 {{{#!hs
 data TcDoc = TcExprDoc CoreExpr
            | TypeDoc TcType
            | InstancesDoc ClsInstLookupResult
            .
            .
            .
 }}}

 Consumers of error messages could then use these annotations as they like.
 Most of the existing consumers would likely expose a function which would
 take a function to project the phase-specific data back to a plain `SDoc`.
 For instance,
 {{{#!hs
 showSDoc' :: DynFlags -> (a -> SDoc ()) -> SDoc a -> String
 }}}
 and we could avoid breaking existing users of `showSDoc` by defining it
 as,
 {{{#!hs
 showSDoc :: Outputable a => DynFlags -> SDoc a -> String
 showSDoc dflags = showSDoc' dflags ppr
 }}}

 Other uses (say, tooling using the GHC API) might choose to instead use a
 richer presentation of the data embedded in the document. These users will
 still be limited by the fact that the error representation is still
 ultimately a pretty-printer document, but at least now we can avoid
 parsing text. Moreover, we might be able to expose more context in this
 embedded data than we show in the current messages.

 One of the nice properties of this approach is that it allows a somewhat
 gradual transition. Adding the infrastructure to enable this sort of
 embedded doesn't requires only minor changes to existing code (e.g. adding
 the index to `SDoc`). Moreover, I have a sneaking suspicion that it would
 allow us to clean up the handling of `Name`s in `Outputable`.

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