[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:  13122
 Related Tickets:                    |  Differential Rev(s):
  #8809,#10073,#10179,#12906         |
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Rufflewind):

 Replying to [comment:56 bgamari]:
 > Phil, I'm not sure I understand your `ELink` constructor. Is the `Int`
 here a stand-in for any old type, or is this really an `Int`? If the
 latter, what does it represent?

 It's meant to be an index that points to the relevant item inside the
 `[(Location, Maybe Expression)]`.  It's not a very good representation for
 links, but that was just a sketch of the general idea.

 > What enables their nice presentation is the fact that the semantically
 rich objects and the pretty-printer documents are one and the same.

 If my understanding of David Christiansen's talk is right, then I don't
 agree that conflating pretty-printer documents and semantically rich
 objects is a good idea, because you are throwing away structural
 information in the process while also committing to a specific
 representation of the error message.  In effect, the burden is shifted
 towards the consumers, because they have sift through the `Doc` to find
 the parts the want (what if they want to rearrange pieces of the error
 message?).  Moreover, if GHC decides to make a superficial change in how
 the errors are laid out, then it will impact downstream consumers.

 If I may draw upon an analogy, this is kind of like if a web API decided
 to, instead of emitting data using simple JSON, emitted full-blown HTML
 files that are many times more difficult to parse while also requiring you
 do sift through the HTML elements to find the parts you want.  Meanwhile,
 you'd worry what would happen to the structure if the web API gets
 upgraded.

 I'm all for semantically rich error messages.  `Error` data type I
 sketched earlier could be tweaked to allow for the kinds of things that
 David Christiansen talks about.  But by keeping the structural information
 it would provide a more informative interface for consumers downstream.
 In other words, I would much prefer:

 {{{#!hs
 Error loc (TypeMismatch expr1 expr2)
 }}}

 than

 {{{#!hs
 docLoc loc <+> text "Type mismatch:" <+> docExpr expr1 <+> "vs" <+>
 docExpr expr2
 }}}

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