Re: Compiler error messages

["Nick Roberts" <Nick.Roberts@dial.pipex.com>]

-- 

Nick Roberts
Croydon, UK

Proprietor, ThoughtWing Software; Independent Software Development
Consultant
* Nick.Roberts@dial.pipex.com * Voicemail & Fax +44 181-405 1124 *
*** Always game for a verbal joust (usually as the turkey) ***


Robert A Duff <robertduff@world.std.com> wrote in article
<En96AJ.JxL@world.std.com>...
> >...I always prefer compilers which simply stop at the first
> >error.
> 
> If the compiler is fast enough, this is acceptable.  But even on todays
> fast machines, I think it's worthwhile to try to do better.  It's pretty
> annoying to run a 15-minute build, go off and eat lunch, and come back
> to find that the compiler (or make facility) stopped on some silly error
> in the first file.

On what machine does an Ada 'rebuild' take 15 minutes?  Ouch!  Even a huge
project shouldn't take that long to do a minimum rebuild (generally): this
is an issue which goes far beyond error messages, to programmer
productivity in general.  One of the things that slows down compilers is
trying to be ultra-clever about errors.  Which would you prefer: compiler
(a) which takes 10 minutes to compile but stops at the first error (and
costs less, and is more reliable); or compiler (b) which takes 15 minutes
and has recovery?

> >My advice to compiler writers would be: make SURE that the compiler
reports
> >any error 100% accurately.  That means making NO assumptions about what
> >caused the error ("oh, it was _probably_ because the user forgot to type
a
> >semicolon", etc...).
> 
> What do you mean by this?  It seems to me that the only way to avoid
> making such assumptions would be for the compiler to have a single error
> message, "This is illegal."  Any "better" error message is necessarily
> making some assumption about what the programmer must have meant to
> write.

See my other post to answer this one.

> Here's an example where a compiler really ought to try to be "clever":
> In Ada, if two packages have a type called Something_Or_Other, and you
> have a use_clause on both packages, then the two Something_Or_Other's
> cancel each other out -- neither one is directly visible.  If I refer to
> Something_Or_Other, I don't expect the compiler to correctly guess which
> one I meant, but I definitely want it to tell me that this
> use_clause-cancellation is happening, and where the two
> Something_Or_Other's are.  I don't want just "No directly visible
> declaration of Something_Or_Other."

I would be really surprised if a compiler giving a "name not visible"
didn't list all the candidates (the entities in the dictionary whose names
could include the offending name).  You mean to say some compilers don't do
this?  Now busy testing...