Re: History of code completion

> So I'm quite interested in the history of code completion in IDE's &
> code editors. Does anyone have any info or personal recollections,
> or even opinions on the merits/demerits of code completion?




It used to be much biger than it is nowadays, as I understand it. One
name for the general area is "syntax-directed editting". I'm a little
curious, myself, why it hasn't caught on more than it has. I wonder
how much it's due to a still-prevailing attitude that Real Programmers
can do it themselves and don't need the help?


Two styles are available for syntax-directed editting. First, the
editor can force you to only generate syntactic forms. To enter a
statement, you select from some kind of menu or keyboard command what
kind of statement you want, and the editor will fill in defaults.
Now, the editor can have a compiled version of the program at all
times. If you want to change the name of a function, you can select
that function and then bring up a menu -- the editor will know that
(a) you have selected a function name, and (b) what functions are in
scope at that point. Squeak's end-user programming tool is a current
system that works like this, but it's not practical for general
programming. (Though there is talk....)


As I understand, programmers who have used traditional tools tend to
get irritated in systems of this first style. That's too bad; it
actually sounds to me like it could be a very smooth programming
experience! Imagine, no syntax errors.... But, I've never actually
tried it.


The other style is to leave the programmer with a general text editor,
and then have the editor maintain a parse tree for what the user has
typed -- essentially compiling while the user types. There are
algorithms for incremental parsing and incremental analysis, e.g.:




      Thomas Reps, Tim Teitelbaum, Alan Demers.
      Incremental Context-Dependent Analysis for Language-Based Editors.
      ACM Transactions on Programming Languages and Systems,
      Vol. 5, No. 3, July 1983, 449-477.


It's tricky, though -- a lot of the intermediate stages aren't going
to be legal code!


This style is used in VB and Smalltalk, and it's used in syntax
highlighters in, e.g., Emacs. The syntax highlighters in particular
often rely on heuristics instead of doing strictly correct parses, at
least if the current buffer has unsyntactic code in it. I honestly
don't know whether this is due to theoretical limitations or just due
to a lack of effort by the authors.




In either style, note that you *have* to have a language-specific
editor or editor mode for this kind of tool to work. For it to work
well, you furthermore need the editor to be integrated with the
compiler (or at least, the editor needs to know about the compiled
codebase.) For some reason, there is a lot of resistance to such
integrated development environments, partially because they tend to
not cooperate well with other languages.


In my more cynical moments, I sometimes wonder if software-development
tools are driven by a desire to make programming remain "fun". What a
crazy bunch we are!


-Lex
[I've used both kinds of editors. The first kind is incredibly
annoying, because there are lots of common and simple text changes
that are large changes in the parse tree, e.g, move a close brace
down a few lines past some other statements. The second kind is still
around. Teitelbaum et al started a company and turned their stuff
into products. See http://www.grammatech.com/ -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.