Re to Dennis Yelle (not about ignorant newbie... :)

> Mary Fernandez <mff@research.att.com> writes:
> >He describes a technique that enables a compiler to emit only
> >non-spurious error messages [...]


Dennis Yelle wrote:
> There is nothing wrong with research into areas like this. But, as a
> compiler user, I would be quite happy with a compiler that gave a
> reasonable message with line number for the first error and then
> aborted. What I don't like is a compiler that continues emitting
> error messages (accurate or not) until the first one rolls off the top
> of my 25 line screen. With the current hardware that is sitting on my
> desk, it is no problem to fire up the compiler again after I fix each
> error.


I must disagree. It's true that the first message bears the
most relevant information, but the next ones can also have some
meaning. If the problem is about height of terminal window, then you
should probably make your programming environment more comfortable
(e.g. by using editor that can display output of the compiler in a
separate window which can be scrolled). You say that your hardware is
so fast, that it lets you to start the compiler after fixing each
error. Computer you're using must be at least Alpha Server then. For
me one of the main problems about debugging is restarting the
compilation after having one or a few bugs fixed, and the time it
consumes. This is visible mostly when compiling long files. I don't
have a slow processor - it's P133.


> My experience, over many years, teaches me that the first error
> message is probably close to being correct, the following ones are
> probably not close to being correct.


I'd rather say that it depends on the kind of error that
appears. If it's caused by - let's say - lack of closing barcket '}',
then you're 100% right. All of the errors reported by compiler are in
that case both obvious and idiotic, so that we want to nod our head
and tell the guy to stop producing it for we know the cause.


But if the first error is due to punctuation mistake, for
instance a misplaced semicolon or something like this, then in most
cases it doesn't have influence on further errors reported. In such
situations you can easily fix two, three or even more bugs withot
starting the compiler again. Consider, that not all the computers are
fast. Besides, everybody is - time to time - forced by circumstances
to write a piece of code on a computer he had never worked on before,
so the programming environment isn't customized according to his
prefs.


And a funny example: The previous week someone asked me to
write a small program under Pascal, language I haven't used for over 3
years. You can't imagine how many {}brackets I had to change to
"begin" "end" or how numerous were the semicolons I forgot to place at
the end of procedure headers. If that compiler stopped after reporting
a single bug, then I probably would have to spend the whole day fixing
the code.


> It seems obvious that you cannot produce a compiler that will always
> give a correct second error message, because the compiler cannot know
> what I actually intended in place of the first error.


Sure. But do you REALLY have no use of further error messages?
If so, then simply get some compiler that doesn't generate it. Or...


> Or give me a command line option for this.


Yes. This solution will satisfy everybody.
--


Jacek - Kak gienij czistoj krasoty
--

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