Re: History of code completion

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

          From comp.compilers

Related articles
[5 earlier articles]
Re: History of code completion gzw@home.com (Geoff Wozniak) (2001-10-27)
Re: History of code completion marcov@toad.stack.nl (Marco van de Voort) (2001-11-05)
Re: History of code completion genew@mail.ocis.net (2001-11-08)
Re: History of code completion binary@eton.powernet.co.uk (Richard Heathfield) (2001-11-08)
Re: History of code completion lex@cc.gatech.edu (Lex Spoon) (2001-11-08)
Re: History of code completion neelk@alum.mit.edu (2001-11-11)
Re: History of code completion rbates@southwind.net (Rodney M. Bates) (2001-11-11)
Re: History of code completion joachim_d@gmx.de (Joachim Durchholz) (2001-11-14)
| List of all articles for this month |

From: "Rodney M. Bates" <rbates@southwind.net>
Newsgroups: comp.compilers,comp.programming
Date: 11 Nov 2001 23:17:31 -0500
Organization: EarthLink Inc. -- http://www.EarthLink.net
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.