Hacker News Reader

Comment by Someone | Hacker News Reader

I strongly disagree. Compilers should autocorrect “obvious” parse errors. I also am not aware of any that doesn’t.

What they shouldn’t do is produce a binary based on their (smart or stupid) guesses about the programmer’s intention.

That allows you to compile, fix multiple typos, compile, instead of compile, fix one typo, compile, fix the next typo, compile, etc, _and_ prevents you from running a program that you didn’t write.

I am not aware of any compiler that doesn’t do this, as it would be extremely annoying to have a compiler give up at the first error.

The search term to use is parser error recovery. It doesn’t give obviously great hits, though. Sample hits:

- https://www.geeksforgeeks.org/what-is-error-recovery/

- https://cs.adelaide.edu.au/~charles/lt/Lectures/07-ErrorReco...

- https://en.wikipedia.org/wiki/Burke–Fisher_error_repair

- https://en.wikipedia.org/wiki/LR_parser#Syntax_error_recover...

View on HN

Not sure why you are being downvoted but you are completely right.

A few years ago GCC wasn't as good at error recovery, so the "too many errors, bailing out" message was a common occurrence (code for Internal Compiler Error, but managed to print at least one diagnostic). Today it is much much rarer to encounter it and using the compiler is a much more pleasant experience.

Unfortunately this isn't so simple. Autocorrecting to something could result in picking something that's actually wrong and impacting whole program semantics, either causing no errors when there should be errors, or causing errors when there should be none. That could be extremely confusing for new developers.

Instead, compiler authors need to understand and prioritize good ergonomics. Diagnostics should be accurate, come with suggestions, have unique error codes you can look up, and follow patterns you can predict over time.

I wasn’t making any claim it’s simple. Writing a compiler is simple (1), writing a compiler that produces good code is hard, writing a compiler that produces good error messages is very hard. Once you can produce good error messages, error recovery isn’t that hard anymore.

I think languages that use different ways to delineate different loops (do…od, if…fi, while…wend, repeat…until) make it easier to do error recovery of “about compilable” source than C-style ones that use {…} everywhere. In general, redundancy will improve the ability to do error recovery.

(1) The trick is to not think about code quality at all. Emit assembly for every individual statement, never inline functions, feel free to write a load from/store to memory for every variable read/write, etc. It will get you slow code, but also code that’s faster than an interpreter for the same language (your version 2 could post-process to eliminate superfluous loads and stores. Even only removing loads gives a speed up and a code size decrease).

As long as compilation is instant, or nearly so, recompiling after each error fixed is likely preferable. The reason being that the error correction is frequently flawed, so that anything beyond the first error is usually suspect, and often will disappear after the first error is fixed. The novice programmer may not realize this, and thus become quite confused when they try to diagnose the later errors, only to realize they don't exist.

> I also am not aware of any that doesn’t.

Can you give an example of CPython, or GCC/clang autocorrecting a parse error?

They do auto correction while parsing. If you have a C code and forget a semicolon or something else. It will try to guess a way to fix it in order to parse the rest of the program, in order to give you other possible errors it found. There even is the -Wfatal-errors flag to disable this functionality.

Have you ever seen GCC or Clang give more than one error message for a program? They're able to provide more than one error message because they correct the first error, and then continue parsing.

For some value of “correct”. Actually, it's often more like skipping a few tokens until some kind of synchronization point (e.g., a semicolon) is reached. It's good manners for a compiler that does this to refuse to produce a binary.

As a clang++ demonstration see https://godbolt.org/z/bTMT6qd4f. The failing `static_assert` uses the variable `i` which comes from the line missing a semicolon. It only reaches this assert because the compiler internally fixed the first error.

Reply on news.ycombinator.com