[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gcc compile-time performance
From: |
Akim Demaille |
Subject: |
Re: gcc compile-time performance |
Date: |
20 May 2002 20:22:24 +0200 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) |
>>>>> "Robert" == Robert Dewar <address@hidden> writes:
>> As noted by Paul Hilfinger in the Bug Bison list, widespread access
>> to interactive computing makes it more prudent with a "compile to
>> the first syntax error, fix, and repeat" approach.
Robert> I know that theory, but in practice we find that in the GNAT
Robert> world, where error messages are good, and the compiler very
Robert> rarely gets derailed, people want to see as much as posisble
Robert> in a single run.
I feel I should cite Paul Hilfinger here, and cc to him.
--------------------------------------------------
To be honest, however bad panic-mode syntactic error recovery might be
in Bison, in practice it doesn't seem so terrible *given how it is now
used.* Back in the good old days when I had to wait quite a while
for a compilation, good error recovery was extremely useful, since it
allowed me to get more errors per run, and therefore significantly
affected productivity. The way I work now, and with the speed of
modern computers, the "compile to the first syntax error, fix, and repeat"
technique has become increasingly viable over the years. That's why I
must admit that it's not easy for me to get terribly excited over
major innovation in this area, and I've just been looking to clean up
a few fringes.
If you do want to implement your idea or something more ambitious, do
be sure to check the literature (Corbett's dissertation has quite a
few pointers, plus caveats about some of the apparently attractive
techniques). It's surprising what can and has been done in this area.
One of my favorites: GNU Ada (GNAT) allows forward declarations of
nested subprograms, which look like this
...
procedure Glorp (X: Integer);
and full subprogram definitions of these nested subprograms, like this:
...
procedure Glorp (X: Integer) is -- YYY
Local_Var: Integer;
begin
...
end;
-- XXX
A common error is to write ";" instead of "is" on line -- YYY. It
then LOOKS like a forward declaration followed by more variable
definitions, followed by the body of the surrounding package or
subprogram. The compiler does not discover a problem until it finds
that -- XXX is not the end of the file. The GNAT compiler actually
reports this error by saying that you wrote ";" rather than "is" on
line YYY, even though the syntax error isn't detected until line
-- XXX. There are automatic techniques that can perform feats like
this---pretty neat.
Paul Hilfinger
Re: gcc compile-time performance, Robert Dewar, 2002/05/20
- Re: gcc compile-time performance,
Akim Demaille <=
Re: gcc compile-time performance, Hans Aberg, 2002/05/20
Re: gcc compile-time performance, Robert Dewar, 2002/05/20
Re: gcc compile-time performance, Robert Dewar, 2002/05/20
Re: gcc compile-time performance, Robert Dewar, 2002/05/20
Re: gcc compile-time performance, Robert Dewar, 2002/05/20
Re: gcc compile-time performance, Robert Dewar, 2002/05/20