> Well it seems to be able to report a lot of syntax errors even if
> they're close together, so it must be getting back on its feet fairly
> quickly. I don't know how that works. Maybe it just scoots along to
> the next semicolon or maybe you explicitly have productions like "if
> (syntax error) { ... }".
>
> What I also don't know is what the parser outputs if there's an error.
> Can it say "he tried to define bool foo() at line 123 but the body was
> erroneous", or does it just stdout the error message and forget there
> was ever an attempt to define foo?
You're missing my point by getting too deep into details. I'm making a
more general point, which is that a parser of a compiler and a source
browser have two different purposes.
The purpose of the former is primarily to produce a parse tree of a correct
program and secondarily to produce as many error messages as possible for
an incorrect program. The purpose of the latter is to try to figure out as
much as it can about the semantic meaning of what may be program fragments
and be completely uncaring about the presence or absence of errors.
Although there is indeed significant commonality between these two
purposes, there are very significant difference as well. For example, a
compiler usually won't look at things such as indentation and whitespace at
all (except maybe when deciding what message to give for errors, but I
think only the Ada front end does this), but high-quality source file
browser would rely more on indentation than the exact parse because the
indentation of a program in the process of being written will usually be
more likely to be able to identify semantic constructs than a parse based
on the tokens in the file.
