help-bison
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]