I am investigating how to design error messages in LFortran, a modern Fortran compiler that we are developing. Our goal is to have the state-of-the-art error messages. I knew Rust has excellent error messages, and learning about how they designed them:
they referenced Elm as an inspiration. So I read about how Elm designed it, I linked the blog posts in the above GitLab link (I can’t post more than 2 links as a new user). And I have a couple questions. It looks like there are slight differences in the Rust design vs Elm design:
Elm seems to print the relevant source code (with just a simple span marker but no label), and then provide most information underneath, such as expected types and other hints
Rust uses primary and secondary markers/spans and labels. The primary is in red, that’s typically the actual error, and then the secondary labels are in blue, and they always reference some spots in the code. They sometimes also print more info underneath if it does not fit the labels.
I noticed people on this Forum often use both Rust and Elm. Which style do you prefer? What are the pros/cons? Or are both equally good, just a personal taste?
Are there some parts that you would improve in Elm and/or Rust?
I agree with the Elm’s blog posts with the motivation for good error messages. My experience with using Rust a little bit is the opposite of a C++ compiler (especially the older ones). With C++ I am dreading to get any error messages. With Rust I am almost looking forward to have a conversation with the compiler. I haven’t used Elm beyond just playing in the online demo, but the error messages experience seems very similar. So both Elm and Rust are my gold standards so far when it comes to error messages.
P.S. I am hoping to figure out a similar “compiler assistant” approach for having back and forth with the compiler with regards to optimizations, how it rewrites the code. That is specific to Fortran, where performance of the numerical code is essential.
Hey @certik , I’ve personally enjoyed both. I think Rust went for more detailed errors since the language complexity requires it. The only issues I’ve had with both is when you get to some edge cases. I’d guess that your audience for a Fortran compiler is more trained (CS degree and the like) than the general target for elm coders, which also includes complete newcomers to programming. So I think I’d go for Rust-like errors.
@mattpiz thanks for the feedback. Great point that it might depend on the target audience, I think that explains it. For Fortran it is actually non CS people: domain scientists (physicists, engineeers, etc.) that are using it to solve problems. Some are new to programming, some are more experienced, but typically programming is not their main expertise, rather it is their domain that is their main expertise (whether physics, numerical math, various branches of engineering, etc.). With a good set of warnings I am hoping the compiler will actually help Fortran users write high quality code.
For now I also decided to go for the Rust style with primary/secondary labels, but also allow attaching a longer comment underneath, like Elm does. In Rust the longer comment is hidden, you have to load it with the --explain option, and it can be a bit long. It seems having a medium size comment like Elm has is helpful.
The rendering requires more work, such as in the first example it should swap the line 3 and 4, etc. But it’s a good start.
While doing this, I realized that the error message rendering is essentially a terminal GUI of an editor with the error markers, and it’s just simplified (and read only). So with this in mind, one can also add syntax highlighting, and show some more text before and after, etc.
One problem with the approach that elm (and rust) have, is that it’s very reliant on colors. This approach has some problems, if you leave the commandline, I’m not sure if your planning on that.
But you might need to have a different output. Elm offers the errors in a json format in addition. Unfortunatly it’s not that helpful, as VSCode for e.g. has no means to style diagnostics right now, so they are always in the same color
