#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