[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:
 Type of failure:  None/Unknown      |  Unknown/Multiple
      Blocked By:                    |               Test Case:
 Related Tickets:                    |                Blocking:
                                     |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by bgamari):

 Replying to [comment:6 diatchki]:
 > It would be nice if we could refactor GHC so that error messages are
 kept in some sort of structured format with all information that might be
 relevant.  Then, when printed we could have flags to specify how to render
 the errors (e.g., "machine form", which would be good for external tools,
 such as IDEs; or "human form", which could have the nice formatting in the
 example).
 >
 Indeed this would be nice, however placing all of the information
 necessary for an error comes at a cost. I think Simon PJ articulates this
 fairly well in this [[comment
 https://www.reddit.com/r/haskell/comments/3bnpa7/compiler_errors_for_humans/csoksqg]]
 on the Reddit post mentioned by goldfire (reproduced here for archival
 sake),

 >Building error messages from strings (or in GHC's case `SDoc`s) is pretty
 lame because you can write them but not analyse them. The "obvious"
 alternative is to use a huge algebraic data type with one constructor for
 each error message that GHC can produce. Then you generate the constructor
 in one place, and render it into a string somewhere else, perhaps in more
 than one way. I am not optimistic about this, because it puts a big
 central road-block in the way of generating error messages, and splits the
 work into two different places (the renderer and the generator). That's an
 advantage in some ways, but there are so darn MANY different error
 messages that it feels far too centralised and brittle to me.
 >
 >Idris does something in the middle. As I understand David Cristiansen,
 they have an abstract type a bit like `SDoc`, but it is much richer than
 GHC's `SDoc`. They can certainly do colour (and `SDoc`s should too). And
 you can attach auxilary info to the `SDoc` so that when rendered in a web
 browser you get popup hints. This would all be very feasible in GHC, if
 someone did the work.
 >
 >Another big issue is having enough information to hand when you are
 generating the message in the first place. Attaching provenance
 information to type constraints is a huge help (as the Elm article
 suggests) which GHC does, but not well enough. For example Lennart
 Augustsson gave a talk at the Haskell Implementors workshop last year with
 some simple suggestions that work really well in his Mu compiler. Jurriaan
 Hage and his colleages at Utrecht have a lot of experience of this kind of
 thing with Helium. GHC is better placed to do this now than it has ever
 been before, because the type inference engine is increasingly based on
 solving constraints. Almost all type errors are generated in a single
 module, `TcErrors`, if you are interested to look there.
 >
 >I'm keen to make sure that running GHC in batch mode sending output to a
 text file or dumb terminal gives something useful. I don't want to require
 a snazzy IDE or emacs mode. But I'd love to be able to exploit one if it
 was available.

 The proposal I lay out in comment:3 was an attempt to find a way to
 implement the alternative that Simon describes above while minimizing the
 impact of the change.

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