Way Way Waaaay Nicer Error Messages

[vramana]

https://reasonml.github.io/community/blog/#way-way-waaaay-nicer-error-messages

I am little suprised nobody that posted this here till now. I hope this will be implemented for ocamlc and ocamlopt compilers as well.

[zozozo]

There’s already https://github.com/ocaml/ocaml/pull/102, though I don’t know if or when it will be merged.

[Leonidas]

I think this is a slightly different focus, with “easy” error messages when compiling the compiler with “easy” error messages. The Reason frontend seems to be more about providing more comprehensive and clear error messages for everybody, in the spirit of Rust.

[zozozo]

Indeed, from what I understand, the reason frontend mainly changes the formatting of the error messages to make them clearer (and more modern), whereas the github PR actually changes the content of the messages.

[dbuenzli]

@Leonidas

The Reason frontend seems to be more about providing more comprehensive and clear error messages for everybody, in the spirit of Rust.

The layout may be a bit better, but it also seem some clarity is lost by avoiding precise terminology — thinking that avoiding precise terminology leads to better usability is a common design mistake.

Also lost it seems, according to that screenshot, a location format that allows to use your editor to jump to the right place in the code – quite a showstopper.

[vramana]

@dbuenzli

The layout may be a bit better, but it also seem some clarity is lost by avoiding precise terminology — thinking that avoiding precise terminology leads to better usability is a common design mistake.

I don’t think avoiding precise terminology is probably a goal. One can improve upon error messages till it’s sufficiently clear. One can do rust style output error code and give more context in seperate place.

@dbuenzli

Also lost it seems, according to that screenshot, a location format that allows to use your editor to jump to the right place in the code – quite a showstopper.

SInce the error messages already print the part of source code with line numbers, editors can be re-configured to read the new error messages or the error messages format can also be tweaked. I don’t see it being quite a show stopper.

[dbuenzli]

@vramana

SInce the error messages already print the part of source code with line numbers, editors can be re-configured to read the new error messages

The current OCaml error messages are much more precise than lines, they get you on expressions, hence it would be show stopper for me.

Once you jumped to the precise place in your file you can then explore the surrounding context with merlin which is a much richer problem solving environment than printing a bit of context on stdout with nice colors.

As far as reconfiguring my editor to recognize these messages, I don’t like to spend time reconfiguring my editor, I have code to write. Not to mention that the format shown would be more difficult to parse. I think compiler tooling should stick to gnu conventions, this maximizes compatibility with a broad range of tooling without needing configuration (see MPR 6518).

So yeah these error message do undeniably look way way waaaay nicer, but as it stands, from a usability point of view, they seem rather a regression.

[yawaramin]

The OCaml compiler currently does not stick to the GNU conventions you linked in any case.

For CLI-based workflows (OCaml builds can be driven nowadays by ocamlbuild, jbuilder, npm, …), it’s undeniably a usability win to have errors visualised. Like Steve Krug said, don’t make me think! Just show me exactly what I need to see.

For editor-driven workflows, we have the OCaml language server (with instructions for editor setup: https://github.com/freebroccolo/ocaml-language-server ). Editors shouldn’t have to parse CLI text output in this day and age, and language servers are thankfully replacing that technique.

[dbuenzli]

@yawaramin

The OCaml compiler currently does not stick to the GNU conventions you linked in any case.

That may be the reason why I linked to MPR 6518 in my previous message.

@yawaramin

For CLI-based workflows (OCaml builds can be driven nowadays by ocamlbuild, jbuilder, npm, …)

[…]

@yawaramin

For editor-driven workflows,

I don’t mind having more context but precise error location reporting is more important. As far as I’m concerned the dichotomy you make here does not exist: I run my build systems both from the command line and from my editor; in the later case being able to jump to the culprits of warnings and errors from all of the tools involved in the build is essential.

@yawaramin

Editors shouldn’t have to parse CLI text output in this day and age, and language servers are thankfully replacing that technique.

Nice, another program to configure and run, why not, “don’t make me think”. I only had a quick glance but I have the impression that this is more something merlin would use. For example how do these things handle build system interaction where the errors come from multiple sources and tools ?

[bluddy]

It would be nice to implement this as a compiler plugin (now that we can), perhaps by default. Expert users could disable it.

[yawaramin]

@dbuenzli

That may be the reason why I linked to MPR 6518 in my previous message.

If we’re being realistic here, I don’t see any evidence that anyone intends to move forward on that. It’s been there for years now. Pointing to that saying, ‘Aha, we’ve already settled on GNU standards!’ is kinda inaccurate.

@dbuenzli

… another program to configure and run …

I’m not sure if you followed the link I gave, it has this line: ‘See vscode-reasonml. The OCaml Language Server comes bundled with this VS Code extension and no additional configuration steps are necessary.’

@dbuenzli

… how do these things handle build system interaction where the errors come from multiple sources and tools ?

With an error list panel like so: https://media.githubusercontent.com/media/reasonml-editor/vscode-reasonml/master/assets/screenshot.png

[dbuenzli]

@yawaramin

Pointing to that saying, ‘Aha, we’ve already settled on GNU standards!’ is kinda inaccurate.

That’s not what I said, please read me more carefully.

@yawaramin

I’m not sure if you followed the link I gave, it has this line: ‘See vscode-reasonml. The OCaml Language Server comes bundled with this VS Code extension and no additional configuration steps are necessary.’

I did and that’s what I found…

@yawaramin

With an error list panel like so: https://media.githubusercontent.com/media/reasonml-editor/vscode-reasonml/master/assets/screenshot.png

I’m not asking about end-user interaction here, I’m asking about the build processing/feedback architecture. This screenshoot doesn’t show a build system running, it shows merlin in action which is quite different. The question is how is this language protocol supposed to interact with your build system (which potentially deals with multiple language/compilers) ?

[yawaramin]

@dbuenzli

That’s not what I said, please read me more carefully.

Actually, in that case I’m not sure what you mean. Would you mind saying it more plainly?

@dbuenzli

I did and that’s what I found…

Yes, tooling providers can often provide one ‘blessed’ stack for everyone to use, and point more advanced users at more configuration options. Perfectly automated support for every editor/IDE is asking rather a lot, IMHO.

@dbuenzli

The question is how is this language protocol supposed to interact with your build system (which potentially deals with multiple language/compilers) ?

No, the question actually was, would these new error messages (which by the way are turned off by default) prevent editor tooling from parsing OCaml compiler errors? And the answer is, no, because the language server protocol doesn’t rely on parsing raw text output.

[dbuenzli]

@yawaramin

No, the question actually was, would these new error messages (which by the way are turned off by default) prevent editor tooling from parsing OCaml compiler errors? And the answer is, no, because the language server protocol doesn’t rely on parsing raw text output.

That’s not what I’m asking but maybe someone familiar with that technology can answer my question which I think was sufficiently clearly exposed.

[Khady]

@dbuenzli

Also lost it seems, according to that screenshot, a location format that allows to use your editor to jump to the right place in the code – quite a showstopper.

It shouldn’t be too hard to fix. I think it has been received by the author and will be worked on. Note that bettererrors which does a bit the same thing and by the same person actually follows the gnu convention. Editor integration is not something that is ignored on purpose.

@yawaramin

For editor-driven workflows, we have the OCaml language server (with instructions for editor setup: https://github.com/freebroccolo/ocaml-language-server ). Editors shouldn’t have to parse CLI text output in this day and age, and language servers are thankfully replacing that technique.

This is not really true. The default mode for bucklescript is for example to parse the output of the compiler. This is how the errors are integrated into vscode tasks and most of the editors. The language server is a very cool piece of software but it is a complement not a replacement. And the language server can definitely parse the output of a cli. It happens very often. Because most of the historic tools are working like this. It happens that for merlin the behavior might be different. But the server is not working only with merlin. And other languages don’t have merlin.

@dbuenzli

For example how do these things handle build system interaction where the errors come from multiple sources and tools ?

The language server would merge the different errors to not display them twice. But it is not “flexible”. For example the OCaml language server doesn’t launch the OCaml compiler, only merlin. If you launch the compiler in your editor, with a vscode task or emacs compile command, you will have both errors from merlin through the language server and errors from the compiler. At this point the language server can’t do anything and one editor plugin or configuration should take care of the de duplication of the messages.

@yawaramin

No, the question actually was, would these new error messages (which by the way are turned off by default) prevent editor tooling from parsing OCaml compiler errors? And the answer is, no, because the language server protocol doesn’t rely on parsing raw text output.

Because the language server doesn’t run the compiler It’s something missing.

The new error format is not easy to parse by editors. And it’s not honest to say that editor should not parse cli output. The problem is actually recognized and a json output has been mentioned for example.

[dbuenzli]

@Khady

Because the language server doesn’t run the compiler It’s something missing.

Is that concept completely missing from the protocol or just from that particular implementation ?

It seems the language server should know how to run the build system — e.g. in a particular environment so that it gets structured output from the compilers/tools that get run — and process the outputs to give to the client.

[Khady]

@dbuenzli

Is that concept completely missing from the protocol or just from that particular implementation ?

I don’t know exactly. I’m not a language server specialist. But if I understand correctly, I don’t think that the compilation is really a concept of the protocol. The server is supposed to gives you errors/warnings, but the way it harvests them depends on each implementation. In the ocaml world, it could be with merlin or by calling the compiler. So I tend to think it is something missing from that particular implement. I don’t know how it is possible to tell the language server how to compile the project though. Because it would have to be different for each project (call make, ocamlbuild, jbuilder or any other command). See https://github.com/Microsoft/language-server-protocol/blame/master/protocol.md#L979-L1185

There is a command part in the protocol. Which might allow the language server to run some commands? But I don’t think the server would use the output of this command. It could be done on the editor side though.

Microsoft/language-server-protocol/blob/main/protocol.md#command

[ShalokShalom]

@vramana

I hope this will be implemented for ocamlc and ocamlopt compilers as well.

+1
I hope so too. ^-^

And how can I use this today in OCaml?
Just by using the Reason tool to convert OCaml into it and run there?

[bobbypriambodo]

@ShalokShalom

And how can I use this today in OCaml?

Just by using the Reason tool to convert OCaml into it and run there?

If you mean using OCaml syntax for BuckleScript, then yes it’s supported out of the box (just enable the option through bsc-flags). But AFAICT it doesn’t support OCaml native yet, since it depends on the patched compiler.

[ShalokShalom]

I mean the error messages.

Is it possible to provide a patch?