#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 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? Not to discourage discussion of other options, but I'd just like to remind everyone that Idris has set some very nice precedent for the semantics- details-in-pretty-printer approach. David Christiansen summarizes this nicely in his HIW 2015 talk, [[https://www.youtube.com/watch?v=m7BBCcIDXSg]]. I'd encourage anyone interested in this ticket to watch this talk. In general I worry that by framing the problem solely in terms of "error messages" as done in comment:52 we miss out on the richness that the Idris folks enjoy. What enables their nice presentation is the fact that the semantically rich objects and the pretty-printer documents are one and the same. This means that any time your error `ppr`s a type/expression/source span/etc. you automatically get a rich representation for free. This is something that I believe would be non-trivial to reproduce in the approach of comment:52. Recall that in GHC we typically build up error messages compositionally from a variety of often nested pieces; it seems to me that by distinguishing "error messages" from `SDoc` we give up the ability to do this (unless, of course, we refactor our error message building blocks in terms of `ErrMsg`, in which case why didn't we just use `SDoc` to begin with?). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:56 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler