|[5 earlier articles]|
|Re: History of code completion firstname.lastname@example.org (Geoff Wozniak) (2001-10-27)|
|Re: History of code completion email@example.com (Marco van de Voort) (2001-11-05)|
|Re: History of code completion firstname.lastname@example.org (2001-11-08)|
|Re: History of code completion email@example.com (Richard Heathfield) (2001-11-08)|
|Re: History of code completion firstname.lastname@example.org (Lex Spoon) (2001-11-08)|
|Re: History of code completion email@example.com (2001-11-11)|
|Re: History of code completion firstname.lastname@example.org (Rodney M. Bates) (2001-11-11)|
|Re: History of code completion email@example.com (Joachim Durchholz) (2001-11-14)|
|From:||"Rodney M. Bates" <firstname.lastname@example.org>|
|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
Return to the
Search the comp.compilers archives again.