Interactive Compilation (Ian Holyer/Richard Noad)
Instead of a compiler simply spewing out a bunch of error messages when it
encounters an error, wouldn't it be better if:
- The compiler used it's knowledge of the program to suggest possible
corrections for the error
- You could select and apply a correction without having to go back to the
source code, manually fix the problem and then start the compilation all over
again (somthing like ispell)
Here's a simple example: the following code contains a common error in Java:
String s = "a string";
int i = s.length;
Current error message: "cannot resolve symbol", which means "I don't know of
any field called length in the class java.lang.String". What it could say is
"The String class does not contain a field named length, did you mean to call
the method length()?"
Handling parse errors this way, while desirable, would involve writing a
parser, which is very time consuming, so it is better to stick to semantic
errors, so that an existing parser can be used. Some initial ideas about
possible techniques for handling unknown symbol or type errors are:
- look for similarly named symbols that do exist
- use some sort of distance measure between names, perhaps like soundex
- split symbol into component words ("someMethodName" -> "some method name") instead of treating symbol as a single word
- using knowledge of common (keyboard) typing errors
- do a thesaurus check, so "getColor" would be a good match for "returnColour"
- use contextual data, such as expected type, to narrow the search
or suggest possible replacements
[ Bristol CS | Index | Research ]