<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi all,<div class=""><br class=""></div><div class="">Alfredo and I are hard at work redesigning GHC's error-message system. It is time for more input, though, from clients of the system -- those writing IDEs and other tooling on top of GHC.</div><div class=""><br class=""></div><div class="">The key question: How would you like your errors served?</div><div class=""><br class=""></div><div class="">Right now, errors are served well-done: fully cooked into structureless strings that can be easily given to users. The problem with this is that IDEs cannot easily intervene between GHC and the users, as all the nutrition (that is, detailed information) has been cooked away.</div><div class=""><br class=""></div><div class="">The new design allows for *structured errors*, where error messages are represented by elements of some error type. Different messages have different constructors of this type, and these constructors can carry auxiliary information. GHC will store these errors raw and cook them (that is, turn them into readable strings) only right before printing them. If the raw messages were somehow passed to IDEs, then IDEs could handle them non-uniformly. (For example, if a module name and a file name are different, the IDE could just present a dialog to the user asking whether the user would like to change one automatically.) </div><div class=""><br class=""></div><div class="">There are a few open questions:</div><div class=""><br class=""></div><div class="">* In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system?</div><div class=""> - One route would be to pass e.g. -fjson-errors, which means that GHC presents the raw messages in a JSON format, for IDEs to parse. That's OK, but it still means that IDEs would have to have their own raw error message types to parse into.</div><div class=""> - Another route would be for the IDE to link against GHC itself, and then invoke the compiler via a function call that returns the raw messages directly.</div><div class=""> - Another route is some kind of middle ground, where the IDE passes e.g. -fbinary-errors=<filename> instructing GHC to write out a binary encoding of its messages to some file (or pipe, I suppose). These could then be deserialized back into GHC's own error types, but running in a separate process (linked against GHC, once again).</div><div class=""> - I'm sure you can come up with other interaction strategies.</div><div class=""><br class=""></div><div class="">* What will an IDE do with these messages? It might have special handling for some, but GHC has a lot of different messages, and I imagine IDEs will want many just to be printed to the user. If an IDE has only the raw message, then the IDE is forced to do all the cooking -- no good. So there must be a way to take a raw message and render it into a user-readable string.</div><div class=""> - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use.</div><div class=""> - GHC could easily export its pretty-printing functions that take in the raw messages and produce rendered ones. But that (again) requires linking against GHC.</div><div class=""><br class=""></div><div class="">Note that we are not (here, yet) discussing errors served at points between raw and well-done, though I would like to do so. Such an error would be rendered into a format where textual bits are interleaved with more structured bits, which would enable e.g. clicking on expressions within error messages to get their types. That (important feature) comes separately.</div><div class=""><br class=""></div><div class="">So: what do consumers want here?</div><div class=""><br class=""></div><div class="">Preview: You can take a look at some raw error messages from the driver in <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533" class="">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533</a>.</div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Richard</div></body></html>