2 ms·

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 b

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://www.geeksforgeeks.org/what-is-error-recovery/ - https://cs.adelaide.edu.au/~charles/lt/Lectures/07-ErrorRecovery.pdf https://cs.adelaide.edu.au/~charles/lt/Lectures/07-ErrorReco... - https://en.wikipedia.org/wiki/Burke–Fisher_error_repair https://en.wikipedia.org/wiki/Burke–Fisher_error_repair - https://en.wikipedia.org/wiki/LR_parser#Syntax_error_recovery https://en.wikipedia.org/wiki/LR_parser#Syntax_error_recover...

Retr0id 5y ago
> I also am not aware of any that doesn’t. Can you give an example of CPython, or GCC/clang autocorrecting a parse error?
- borodi 5y ago
  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.
- chrisseaton 5y ago
  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.
  - vincent-manis 5y ago
    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.
- zauguin 5y ago
  As a clang++ demonstration see https://godbolt.org/z/bTMT6qd4f 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.
syrrim 5y ago
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.
gpderetta 5y ago
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.
phillipcarter 5y ago
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.
- Someone 5y ago
  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).

Retr0id 5y ago

> I also am not aware of any that doesn’t. Can you give an example of CPython, or GCC/clang autocorrecting a parse error?

borodi 5y ago
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.
chrisseaton 5y ago
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.
- vincent-manis 5y ago
  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.
zauguin 5y ago
As a clang++ demonstration see https://godbolt.org/z/bTMT6qd4f 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.

syrrim 5y ago

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.

gpderetta 5y ago

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.

phillipcarter 5y ago

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.

Someone 5y ago
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).