15

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.

Improve this question
  • 3
    Does IntelliSense fall into this category? Many compilers have errors similar to [semicolon] expected. – Robert Harvey Dec 27 '10 at 7:11
  • 1
    @Robert: No, but that's a good point. – Nathan Osman Dec 27 '10 at 7:15
  • 1
    A friend of mine did quite a bit of hacking on the C preprocessor, for instance 'inlcude -> include', and some work on trying to figure out where open conditionals should have been closed. It was his master's thesis, which he quickly abandoned for something easier. Still, quite an interesting question! – Tim Post Dec 27 '10 at 16:54
  • 3
    A C# compiler fails with VERY useful error messages. That combined with good documentation available online for every error code works rather well. It is a bad idea to auto-correct syntax, although HTML interpreters (e.g. browsers) often do it anyway. – Job Dec 27 '10 at 19:15
  • 1
    The compiler you are referring to was the original PL/I. It assumed whatever the programmer wrote must have meant something, and tried to guess what that might be. In my experience, it guessed very badly indeed! – david.pfx Mar 22 '14 at 14:03

12 Answers 12

Active Oldest Votes
28

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.

Improve this answer
  • 4
    This is the right answer. Once a compiler can recover from an error, it's no longer really an error. Perl is (in?)famous for this "Do What I Mean" behaviour, choosing what the programmer is most likely to have meant given ambiguous source. – Jon Purdy Dec 27 '10 at 19:45
  • Perl sacrifices verbosity for source code size. – Nathan Osman Dec 28 '10 at 0:33
  • @George Edison: That's either a tautology or a contradiction. – Jon Purdy Dec 28 '10 at 8:08
  • Or a deep insight. :) – Lennart Regebro Dec 28 '10 at 8:09
23

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.

Improve this answer
  • 5
    I know that. Such a compiler would have no use for compilation, but the concept is quite interesting and has learning potential. – Nathan Osman Dec 27 '10 at 8:24
  • 2
    almost all latest IDE provides suggestion for syntax and it is really helpful. and for the rest of the part agree with nganju – jmj Dec 27 '10 at 11:44
  • I would not use such a compiler. It comes under the heading of 'black magic'. – Michael K Dec 27 '10 at 13:59
  • Hmmm where would you rate Scala's type inference on this scale ? Having tried it, it'd say it's a major contribution to concise code. On the other hand, it has occasionally shot me in the foot (e.g because I thought I was dealing with lists but actually was still dealing with sets). – timday Dec 27 '10 at 16:54
  • We have stuff like autoscope in OMP, so a little bit of it is doable. Of course the code I work on has turned autoscoping off because we don't trust it. I could see having an interactive compiler that ask's "did you mean XXX?". Thats as far as I'd be willing to go. And even that is probably too dangerous. – Omega Centauri Dec 28 '10 at 2:25
12

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.

Improve this answer
  • I wish my employer had the resources to experiment like that; we do not even run unit tests at night because there are so many features to add and bugs to fix :( – Job Dec 27 '10 at 19:20
  • 1
    This is the kind of answer I was hoping for... as I mentioned before - obviously such a feature has little practical use, but would provide a great way to learn some techniques that could be applied to other things. (Language parsing, etc.) – Nathan Osman Dec 27 '10 at 19:52
  • 1
    @Job: General wisdom is that if you don't regularly run the unit tests, you'll have a lot more bugs to fix. – Eric Lippert Dec 27 '10 at 23:36
  • I already know what I need to do about my job instead of whining here. At some software companies people at the top do not really understand the difference between a prototype and a finished product. After all, pixel-wise there is often not much of a difference. It is unwise not to start with a prototype, so that time is not wasted. But the dreadful response "looks good, how many days to move this into production?". Those are the same people who would be suspicious if engineers told them that they need to spend time on the infrastructure or refactoring. I hear even Spolsky does not like it. – Job Dec 28 '10 at 2:44
10

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.

Improve this answer
  • 1
    I heartily agree with the JavaScript semi-colon insertion feature - completely useless. – Nathan Osman Dec 28 '10 at 0:32
7

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.

Improve this answer
  • 1
    Such technology cannot exist. Mind reading is not allowed; all instructions must unambiguously come from code. – Job Dec 27 '10 at 19:17
  • True, but what I really meant was "Are there any compilers that attempt to correct invalid syntax by making guesses based on context." The fact that the compiler corrects invalid syntax does not make the syntax valid. Also, I realize that such a tool would be useless for code development. – Nathan Osman Dec 28 '10 at 0:31
6

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();
Improve this answer
  • It should be noted that XHTML provided a solution for the mess that HTML's poor specifications created. – Nathan Osman Dec 28 '10 at 0:35
  • 2
    if (x && y) dothis(); else dothat(); would look slightly better. – Job Dec 28 '10 at 4:48
  • 1
    A cat dies every time someone compares against true or false. – JensG Feb 22 '14 at 20:31
2

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.

Improve this answer
  • 2
    Those compilers would continue, but they would continue ONLY for the purpose of trying to find further errors, so you could (potentially) fix several things before resubmitting. Modern PCs are fast enough that it is entirely feasible for an "interactive" compiler to stop at the first syntax error and drop you into an editor. (And, in fact, the original Turbo Pascal, in the early 1980s, worked exactly that way. It was nice.) – John R. Strohm Dec 27 '10 at 18:19
  • 1
    Yes, I remember the IBM PL/I optimizing compiler would supply missing BEGIN and END statements occasionally, ISTR it would also provide missing semicolons. – TMN Jan 31 '11 at 19:54
1

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.

Improve this answer
0

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.

Improve this answer
-1

Such a compiler would simply be a relaxed, non-standard implementation of whatever language it's compiling.

Improve this answer
-2

It has been tried multiple times, but often it didn't achieve the desired effect: think HAL 9000 or GlaDOS.

Improve this answer
-3

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.