10:55 pm, 23 Aug 03
parse as you type
In compilers class we were told that a significant portion of the compile time (the majority?) is spent in the parsing and lexing stages. Beyond precompiled headers, I've also seen work that keeps compiled versions of files around in memory.
We have gobs of RAM now, and these fast processors that are usually idle while you type and then suddenly strained when you compile. Why doesn't the IDE continually build parse trees as you type? They have to do some preliminary parsing already to do syntax highlighting. But with more of the compiler integrated you not only get more contextual help (see, for example, Visual Studio, which shows you in a tooltip the type of the argument expected for the function you're calling), but also an incredible boost in compile time.
(This seems obvious enough that someone would be doing research in it...)
We have gobs of RAM now, and these fast processors that are usually idle while you type and then suddenly strained when you compile. Why doesn't the IDE continually build parse trees as you type? They have to do some preliminary parsing already to do syntax highlighting. But with more of the compiler integrated you not only get more contextual help (see, for example, Visual Studio, which shows you in a tooltip the type of the argument expected for the function you're calling), but also an incredible boost in compile time.
(This seems obvious enough that someone would be doing research in it...)
But it's not what you were talking about in your post: after the debugging session terminates, the source file is recompiled to produce an up-to-date binary on the disk. And anyhow, it still doesn't compile WHILE you're editing code, but only when you issue a debugging navigation command (such as Step Out).
Even the Perl plugin keeps running the compiler.
I'm not sure about the Visual Studio.NET IDE, but the VB6 “suggest what might complete this statement” system was pretty dumb. It just picked up you either typing
., at which point you are accessing a member in the thing before the dot, so all of the members are presented,As, in which case you are given a list of all types available (as infred As Integer) and=, where if the preceeding name is either boolean or an enumeration you are given a list of options. You can see this just by typing “As” completely out-of-context.The only really tricky bit of it is when it parses each line as you enter it, and flags simple syntax errors. It seems this is done as you leave a line in the editor after changing it. I'm assuming that it's at this point it adjusts its table of local and global variables and their types for the autocomplete.
VB6 is quite a good language for parse-as-you-type, actually, because it has no external compiler: the only way to compile is through the IDE. Unfortunately, VB.NET now has an external, command-line compiler which the IDE launches.
Taking a compiler and integrating its parsing stage into an editor sounds like an interesting project. I'd be interested to see the results.