On May 3, 2021, at 3:11 PM, Chris Smith wrote:

Thanks, Richard. This is awesome!

Glad you're excited. I am, too!

For my use case, the more exciting possibility would be to interact with error messages from JavaScript. For this reason, I'd definitely love to see a well-known structured file format (JSON, YAML, XML, or whatever) that can be read without linking against GHC. I also like the idea of producing both the structured data and the raw string, since as you mention, one shouldn't need to handle every single possible GHC diagnostic just to add some special handling for a few of them.

Ultimately, if reading error messages did require linking with GHC, it wouldn't be the end of the world. I would just write my own translation layer to JSON. So consider this a weak preference.

It would be straightforward to, say, define instances of ToJSON and FromJSON for all of our error types. We could then serialize to JSON. The problem would be that these error types are likely to wibble and wobble between releases. (For now, I would say even between minor releases.) So if you don't link against GHC, you would have to stay on your toes to keep your parser up-to-date. Maybe this feature will settle down into a rhythm, and we can start to promise more stability, but I think it would be a mistake to promise that too soon. Linking against GHC protects you from making a mistake in this regard. On the other hand, the JSON output would be perfectly well formed independently of GHC, so there would be no hard requirement to do this linking. So that's one vote for JSON (where the JSON also includes the rendered string). Do I hear any others? (Note that these different modes of interaction are all pretty easy to build -- the hard part is the infrastructure supporting them -- so we can likely do more than one.) Thanks, Richard

On Mon, May 3, 2021 at 3:00 PM Richard Eisenberg mailto:rae@richarde.dev> wrote: Hi all,

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.

The key question: How would you like your errors served?

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.

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.)

There are a few open questions:

* In what vessel shall the raw messages be served? In other words, how do IDEs expect to interact with this new system? - 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. - 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. - 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). - I'm sure you can come up with other interaction strategies.

* 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. - Maybe the above methods produce both the raw error and the rendered one? Then the IDE can choose which it prefers to use. - 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.

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.

So: what do consumers want here?

Preview: You can take a look at some raw error messages from the driver in https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5533.

Thanks! Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org mailto:ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs