From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d19d0e4c5bf9986f
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1995-02-23 18:35:07 PST
Path: 
 nntp.gmd.de!stern.fokus.gmd.de!ceres.fokus.gmd.de!zib-berlin.de!news.mathworks.com!panix!cmcl2!thecourier.cims.nyu.edu!thecourier.cims.nyu.edu!nobody
From: dewar@cs.nyu.edu (Robert Dewar)
Newsgroups: comp.lang.ada
Subject: Re: Learn the jargon (was: Please explain why this is wrong...)
Date: 23 Feb 1995 21:35:07 -0500
Organization: Courant Institute of Mathematical Sciences
Message-ID: <3ijgkr$778@gnat.cs.nyu.edu>
References: <3ig4uq$13v@explorer.csc.com>
NNTP-Posting-Host: gnat.cs.nyu.edu
Date: 1995-02-23T21:35:07-05:00
List-Id: <comp.lang.ada>

Jeffrey says"

"If you're going to learn the language, you've got to learn the language.
The reference manual is *the* definition of the language and if you're
an Ada programmer, how can it be unfamiliar?


It can certainly be unfamiliar, how many experienced ada programmers
talk about package specifications (when they mean package declarations),
or rep specs (when they mean representation clauses). 

An error message that depended for instance on the reader knowing that
the tag is not part of the value of a tagged type instance would likely
be confusing even to most experienced Ada programmers.

After all, if you really know Ada, and you really know the RM, you shouldn't
be making errors in the first place, and you should be happy with an error
message that says "sytax error".

In dealing with GNAT bug reports we notice a huge number of cases in which
people write what I would call "fantasy code", that is they use a construct
which is not in the language at all, but which seems reasonable to them.


The function of error messages in such a case is to inform the uninformed
user. In particular error messages should have the following qualities:

   o  They are enlightening to the novice user who does not know Ada well

   o  They are not misleading to experienced users who *do* know the
	language well.

As an example, consider a little change we made in an error message the
other day. We used to say:

    prefix of "access" attribute must be an aliased view

and we changed it simply to:

    prefix of "access" attribute must be aliased

Now if you know the language well, you see that the first error message
is slightly more correct, but the use of the word view here is, in my
opinion, likely to confuse a novice user. On the other hand, I don't
think an experienced user is going to look at the second error message
and be puzzled.

As another example of Ada terminology that I think most Ada programmers
don't necessarily know, hands up those who immediately know that the
term package does not include generic package. Now in fact those of
us who have played language lawyer know this well, and our hands will
shoot up. Nevertheless, an error message whose meaning depended on this
fact would likely confuse.

THe whole point here is that error messages are supposed to enlighten 
the user as to the proper corrective action, and have to accomodate a
wide variety of concerns, including the concern of keeping error messages
reasonably terse (some people like their compilers to print essays aout
errors, but most people don't).

P.S. we work VERY hard to try to give good error messages in GNAT, if you
find an error message you don't like, even a little, send it along to
us. We may not always be able to improve the situation, but we often can :-)