I heard a while back that there used to be a compiler that attempted to fix syntax errors by analyzing context and inferring what was intended.
Does such a compiler really exist? Obviously it has little practical value, but would be very interesting to play with and learn from.
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
In some sense, the act of compiling is inferring what certain syntax is meant to do, and hence a syntax error is when the compiler isn't able to figure it out. You can add more "guessing" to have the compiler infer further things and be more flexible with the syntax, but it must do this inferring by a specific set of rules. And those rules then become a part of the language, and is no longer errors.
So, no, there are no such compilers, really, because the question doesn't make sense. Guessing what syntax errors are meant to do according to some set of rules just becomes a part of the syntax.
In that sense, there is a good example of a compiler that does this: Any C compiler. They will often just print out a warning of something that isn't like it should be, and then assume you meant X, and go on. This is in fact "guessing" of unclear code (although it's mostly not syntax per se), something that just as well could have stopped compilation with an error, and therefore qualify as an error.
Sounds really dangerous. If a compiler tries to infer your intent, infers it wrong, fixes the code, and then doesn't tell you (or tells you in some warning that you, like everyone, ignore), then you're about to run code that may seriously do some damage.
A compiler like this is probably something that has very intentionally NOT been created.
The IDE for a programming language usually these days has a compiler running in the background somehow, so that it can provide analysis services like syntax colouring, IntelliSense, errors, and so on. Obviously such a compiler needs to be able to make sense of deeply broken code; most of the time when editing, code is not correct. But we still have to make sense of it.
However, usually the error recovery feature is only used during editing; it doesn't make a lot of sense to allow that for actual compilation in "mainline" scenarios.
Interestingly, we did build that feature into the JScript.NET compiler; basically it is possible to put the compiler into a mode where we allow the compiler to proceed even if an error is encountered, if the IDE would have recovered from it. You can type Visual Basic code in, run the JScript.NET compiler on it, and have a reasonable chance of a working program coming out the other end!
This is an amusing demo, but it turns out to be not a very good feature for "mainline" scenarios for a lot of reasons. A full explanation would be quite lengthy; the brief explanation is that it makes for programs that work unpredictably and by accident, and it makes it hard to run the same code through multiple compilers, or multiple versions of the same compiler. The large expenses the feature adds are not justified by the small benefits.
Peter Torr, who PM'd the feature back in the day, discusses it briefly in this blog posting from 2003.
Though we do expose this feature via the script hosting APIs of the JScript .NET engine, I don't know of any real customers that ever used it.
The first thing that comes to my mind is Javascript's automatic semi-colon insertion. A horrible, horrible feature that should never have made its way into the language.
That's not to say that it couldn't have done a better job. If it looked ahead at the following the line, then it might be able to make a better guess as to the programmer's intention, but at the end of the day, if there's multiple valid ways the syntax could have gone, then there's really no substitute for the programmer being explicit.
It sounds to me that if a compiler could fix incorrect syntax, then that syntax should be documented in the language.
The reason for syntax errors is because a parser could not create the abstract syntax tree out of the program. This happens when a token is out of place. In order to guess where that token should be, if it should be removed, or if some other token should be added to fix the error you would need some sort of computer that can guess the intent of a programmer. How could a machine guess that:
int x = 5 6;
Was supposed to be:
int x = 5 + 6;
It could just as easily be any of the following: 56, 5 - 6, 5 & 6. There is no way for a compiler to know.
That technology doesn't exist yet.
While not quite the same thing, this is sort of why HTML turned into the disaster it is. Browsers tolerated bad markup and next thing you knew, browser A couldn't render the same way Browser B did (yes there's other reasons, but this was one of the top few, esp around 10 years ago before some of the looseness rules became convention).
As Eric Lippert infers, many of these things are best handled by the IDE, not the compiler. That let's you see what the automatic bits are attempting to screw up for you.
The strategy I think that is predominant now is continual language refinement instead of loosening up the compiler: If it truly is something that the compiler can figure out automatically, then introduce a well defined language construct around it.
The immediate example that comes to mind is auto-properties in C# (not the only language that has something similar): Given that the majority of getters/setters in any app are really just wrappers around a field, just allow the developer to indicate their intent and let the compiler inject the rest.
Which then gets me to thinking: Most C style languages already do this to some extent. For things that can be figured out automatically, just refine the syntax:
if (true == x)
{
dothis();
}
else
{
dothat();
}
Can be reduced to:
if (true == x)
dothis();
else
dothat();
In the end, I think it comes down to this: The trend is that you don't make the compiler "smarter" or "looser". It's the language that is made smarter or looser.
Besides, too much "help" can be dangerous, such as the classic "if" bug:
if (true == x)
if (true == y)
dothis();
else
dothat();
When I was coding FORTRAN and PL/I back in the late 80s and early 90s on DEC and IBM minicomputer and mainframe systems, I seem to remember the compilers would regularly log out messages like "blah blah error; assuming blah blah and continuing...". Back then, this was a legacy of the (even earlier, before my time) days of batch processing and punched cards when there was likely an enormous wait between submitting your code to run and getting the results back. So it made a lot sense for compilers to make an attempt to second-guess the programmer and carry on rather than abort on the first mistake encountered. Mind you, I don't remember the "corrections" being particularly sophisticated. When I eventually moved onto interactive Unix workstations (Sun, SGI etc), I did notice the feature seemed to be entirely absent from their C compilers.
The goal of a compiler is to produce executables that behave as desired. If a programmer writes something which is invalid, even if the compiler can with 90% probability guess what was intended, it would generally better to require the programmer fix the program to make the intention clear, than have the compiler go ahead and produce an executable which would have a significant chance of concealing a bug.
Of course, languages should generally be designed so that code which clearly expresses intention will be legal, and code which does not clearly express intent should be forbidden, but that doesn't mean they are. Consider the following code [Java or C#]
const double oneTenth = 0.1;
const float oneTenthF = 0.1f;
...
float f1 = oneTenth;
double d1 = oneTenthF;
Having a compiler add an implicit typecast for the assignment to f1 would be helpful, since there's only one logical thing the programmer could want f1 to contain (the float value closest to 1/10). Rather than encouraging compilers to accept improper programs, though, it would be better for the spec to allow implicit double-to-float conversions in some contexts. On the flip-side, the assignment to d1 may or may not be what the programmer really intended, but there's no language rule forbidding it.
The worst sorts of language rules are those where compilers will make inferences in cases where something couldn't legitimately compile otherwise, but where a program might "accidentally" be valid in a case where inference had been intended. Many situations involving implicit end-of-statement fall into this category. If a programmer who intends to write two separate statements omits a statement terminator, a compiler might usually manage to infer the statement boundary, but might occasionally regard as one statement something that was supposed to be processed as two.
Syntax errors are especially hard to correct. Take the case of a missing right ): We knwo we can repair the code by inserting one, but there are usually many places where we could insert one and obtain a syntactically correct program.
A much easier point are misspelled identifiers (but note this are not syntax errors). One can compute the edit distance between the unresolvable identifier and all identifiers in scope, and by replacing the unresolvable word with the one the user most likely meant, one would come up with a correct program in many cases. However, it turns out that it is still better to flag the error, and let the IDE suggest valid replacements.
Such a compiler would simply be a relaxed, non-standard implementation of whatever language it's compiling.
It has been tried multiple times, but often it didn't achieve the desired effect: think HAL 9000 or GlaDOS.
In C, you cannot pass arrays by value, yet the compiler allows you to write:
void foo(int array[10]);
which is then silently rewritten as:
void foo(int* array);
How stupid is that? I would prefer a hard error here instead of silent rewriting, because this special rule has led many programmers to believe that arrays and pointers are basically the same thing. They are not.
