Re: History of code completion

"Rodney M. Bates" <>
11 Nov 2001 23:17:31 -0500

          From comp.compilers

Related articles
[5 earlier articles]
Re: History of code completion (Geoff Wozniak) (2001-10-27)
Re: History of code completion (Marco van de Voort) (2001-11-05)
Re: History of code completion (2001-11-08)
Re: History of code completion (Richard Heathfield) (2001-11-08)
Re: History of code completion (Lex Spoon) (2001-11-08)
Re: History of code completion (2001-11-11)
Re: History of code completion (Rodney M. Bates) (2001-11-11)
Re: History of code completion (Joachim Durchholz) (2001-11-14)
| List of all articles for this month |

From: "Rodney M. Bates" <>
Newsgroups: comp.compilers,comp.programming
Date: 11 Nov 2001 23:17:31 -0500
Organization: EarthLink Inc. --
References: 01-10-091 01-10-112 01-10-123
Keywords: editor, design, practice
Posted-Date: 11 Nov 2001 23:17:31 EST

"Lasse Hillerĝe Petersen" wrote:
> The once very popular THINK Pascal compiler for the Macintosh also
> worked in that fashion. The program text was parsed until the first
> syntax error, after which text was rendered in outline font.
> ....snip ....
> Having spent my teenage years hacking in COMPAS (which later became
> Turbo) Pascal, I appreciate the combination of a fast compiler with
> the simplicity of always only having to deal with the first occuring
> syntax error.

Well, I hated Turbo Pascal for exactly the same reason. I found
correcting only one CT error at a time took far longer that doing them
in larger batches. Also, I sometimes prefer to choose an order of
work other than source file order. It was especially tedious when
porting existing code.

The total compile time to get a clean compile was O(N**2), because
every time you fixed one problem, it started over at the beginning,
recompiling everything it had done the previous time, before getting
to the new part between the last and the next error. It also took
more keystrokes than just moving to the next error. Of course, that
was on a very slow machine, by today's standards.

My view was that the claims that this was a wonderful feature were
just rationalization for compiler writers' not wanting to do the work
of error recovery. I do know that's a lot of work and it never
performs nearly as well as one would like, but I still prefer it.
Rodney M. Bates

Post a followup to this message

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