Re: History of code completion

Rodney M. Bates <rbates@southwind.net> wrote:
> "Lasse Hillerĝe Petersen" wrote:
> >>
> > 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.


I didn't like this myself, and I would have preferred an
error-recovering compiler.


But that's about the only point that I agree with:


> 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 was (very little time)^2, which was fast enough. Even on machines
that were considered slow in the times of Turbo Pascal. Of course,
this worked only because the compiler was smart enough to recompile
only those modules that needed recompilation. Early versions of Turbo
Pascal that did not have modules might have suffered from this N^2
problem.


-> Conclusion for compiler and language designers: if you don't have
error recovery, make sure that you have separately compilable modules,
and make sure that the compilation is guided by 'make' or a similar
dependency analysis algorithm.


> It also took more keystrokes than just moving to
> the next error.


Not really. Recompilation was never more than a function key away. I
remember that starting recompilation was an entirely subconscious and
automatic process, essentially the same as jumping to the next error.
Of course, if you insist on going through the menu for a
recompilation, then it's many more keystrokes. But jumping to the next
error can be just as many or few keystrokes as starting recompilation;
that's just a question of appropriate key bindings, totally unrelated
to the question whether the next error is located by recompilation or
by consulting an error list.


> Of course, that was on a very slow machine, by today's standards.


These machines were really fast enough. Compilation never disrupted my
flow of thought, and that means it was fast enough for me, even though
I didn't have the fastest available hardware.


> 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.


Agreed. But it would have been really stupid marketing if they had
emphasized that it's a limitation of the product.


I have been involved in some compiler work, and the main issue isn't
whether the compiler manufacturer does or does not do some work - you
can be pretty sure that the available manpower is dedicated to
improving the product.


The real question is where this manpower is directed. If introducing
error recovery would have delayed the introduction of modules by half
a year, I would have preferred modules. Similar for the object stuff
(which wasn't great but very, very workable).


In a similar vein, I didn't like the generated object code, but I
preferred a rather bug-free, surprise-free, and quickly released
compiler to the highly optimizing but late, unstable, and unreliable
compilers that were available elsewhere.


> 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.


Agreed again.


Regards,
Joachim

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