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
#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]: 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).
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
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/...]] on the Reddit post mentioned by goldfire (reproduced here for archival sake), 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