#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