#8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | TypeErrorMessages 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,#13670 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, Richard has a student looking at error messages this summer; one of the later tasks on their list is the sort of rich error message AST described in comment:3. We discussed the design during my visit a few weeks ago and generally agree on this plan: * Decouple the choice of pretty-printer library (#14005) from the error message design as the former has proven to be rather tricky. Note that this might mean that we have to give up a little bit of the progress that we've made on unify our `pretty` fork with upstream, but IMHO the user- facing goal of improving error messages takes precedence to this internal engineering goal. * Don't introduce a type argument to the `SDoc` type; rather define it as it's defined today but against an annotated `Doc` type (e.g. using `pretty`'s annotated `Doc` instantiated at a concrete type of error message items: {{{#!hs type SDoc = DynFlags -> Doc GhcErrItem }}} * Start by defining only a small set of error message items. For instance, perhaps we start with only, {{{#!hs data GhcErrItem = SuggestLangExt [LangExt] -- ^ A suggestion to enable a language extension | AnIdent Id -- ^ An identifier | AType Type -- ^ A type }}} The point here is that the design of this sum should be very much driven by what down-stream consumers need. By starting small we avoid getting bogged down in these tricky design details. Anyways, I suspect that, if defined this narrowly, this project should be quite manageable and will allow us to finally make some progress on this goal. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8809#comment:77 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler