Getting GNAT to issue ARM error messages

Getting GNAT to issue ARM error messages

[David Peterson]

Dear All,

I'm fairly new to Ada, and hope that this is the right newsgroup in which
to post a question specific to the GNU/ACT GNAT compiler ...

Can anybody tell me if/how it is possible to make the GNAT Ada compiler
issue references to the Ada Reference Manual rather than, or in addition to,
the regular error messages issued by the compiler ?

I know that other Ada compilers such as Vertix and VADS can do this, and
am surprised that the GNAT compiler does not do this by default. If it was
a design decision, I'd be interested to hear the rationale behind it.

Regards,



David Peterson

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

In article <F6tqMF.Lz7@syd.csa.com.au>,
  davidp!nospam!@!nospam!syd.csa.com.au wrote:
> Dear All,
>
> Can anybody tell me if/how it is possible to make the
> GNAT Ada compiler issue references to the Ada Reference
> Manual rather than, or in addition to, the regular error
> messages issued by the compiler ?

> I know that other Ada compilers such as Vertix and VADS
> can do this

Actually the latter are the wrong comparison points, since
these are Ada 83 compilers, and in our view the situation
with Ada 95 is quite different from Ada 83.

We only give Ada 95 RM references in rare cases where they
are actually helpful. In our experience, most of the time
if a well thought out error message is not clear to a user,
then they probably do not have the level of knowledge
necessary to benefit from going to the reference manual.

We prefer to work on making the error messages as clear as
possible to someone who is NOT a language expert and NOT
comfortable reading the reference manual. That is the goal.

If there are very specific instances where you think an RM
reference would be helpful, by all means point them out,
but we definitely think that giving RM references on all
error messages is useless and annoying:

   a := xyz;
        |
        xyz is undefined

is about as clear as you can get, putting in an RM
reference to the rather complicated section of the
RM that talks about declaring entities and when they
are visible is unlikely to help anyone!

Generally people have found GNAT error messages to be
very clear -- we certainly put a lot of effort into
achieving this goal, and we know lots of people who
have chosen GNAT for education and other uses of Ada
because of its clear messages.

We do NOT think that adding RM references would help in
the goal of continued improvement of GNAT messages.

This is actually an old thread, discussed before.

One point here is that if you are used to an Ada 83
compiler, the comparison is a bit of an apples and oranges
one, since the Ada 95 RM, in a (successful) attempt to be
more precise is definitely much less accessible than the
Ada 83 RM to a novice reader.



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Tom Moran]

> the Ada 95 RM, in a (successful) attempt to be
>more precise is definitely much less accessible than the
>Ada 83 RM to a novice reader.
  How about references to the Ada 83 RM, then.  Or better, a new doc
which is stylistically as helpful as the 83 RM, but covers the 95
changes.
  One problem with any message is that what's crystal clear to the
author is not necessarily so to all readers.  It's useful in anything
to have alternate sources of explanation, not because one is
necessarily clearer in all cases, but just because having the same
thing described in two different ways decreases the probability that
any given reader will still not understand.

Re: Getting GNAT to issue ARM error messages

[Robert Dewar]

In article <36c1c82d.1234350@news.pacbell.net>,
  tmoran@bix.com (Tom Moran) wrote:
> > the Ada 95 RM, in a (successful) attempt to be
> >more precise is definitely much less accessible than the
> >Ada 83 RM to a novice reader.
>   How about references to the Ada 83 RM, then.  Or
> better, a new doc
> which is stylistically as helpful as the 83 RM, but
> > covers the 95 changes.

Once again, I will say that what is useful is *specific*
examples of error messages that illustrate the point you
are trying to make, along with suggestions for
improvements. It is surprising (and disappointing) that
the long thread on this subject a few months ago did not
result in even ONE suggestion of a message where an RM
reference would be helpful.

Indeed several people who contributed to the thread saying
they would like RM references had not even seen error
messages from GNAT, and in one case they had not even read
the Ada 95 RM :-)

We do get suggestions on error messages from our users,
particularly from students of Martin Carlisle and Michael
Feldman (thank you very much for these contributions), and
we constantly try to improve error messages in GNAT.

If you find an error message you think could be clearer,
send along a note to report@gnat.com. Even if you think you
are being unreasonable in asking GNAT to do a better job in
some particular situation, don't hesitate to suggest,
sometimes things that look really hard turn out to have a
possible solution, and giving good error messages is
something we put a lot of effort into!

Robert Dewar
Ada Core Technologies


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Ehud Lamm]

One comment.

Robert is aiming Ada students, that try to prodcue code and need the error
messages to help thm with errors, and do not need obscure RM references
which in many cases do not help.

What about students of the RM trying to undersatnd what and where each
rule comes from? In these cases an RM or better yet an AARM ref. will be
great, don't you think?

Let me give you a small example, which I am sure will make me a laughing
stock:

type help is (a,b);
type Var(T:help)  is 
        record
         case T is
            when a => 
               data:integer;
            when b =>
               data:float;       -- Same name can not appear twice!
         end case;
         end record;
         

This will not compile, giving the message: "data" conflicts with
declaration in line ..

This seesms obvious enough.

However now suppose I want to find out where is this rule in the RM. 
So I start reading 3.8.1 Variant Parts and Discrete Choices, which is
quite dense reading...

A paragraph, AARM ref. and any other info is always good - if it does NOT
obscure the helpful message whcih the compiler should give, and which GNAT
most often does give.

I think Robert, that you say you have a dream of such a system, so I am
not sure how far our views on this are.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Getting GNAT to issue ARM error messages

[Robert Dewar]

> A paragraph, AARM ref. and any other info is always good
> - if it does NOT
> obscure the helpful message whcih the compiler should
> give, and which GNAT most often does give.

This is the "do no harm" approach, but for me the criterion
is "do good". In other words, your idea that extra
information is always useful if it does not obscure
things is not good enough for me, I would add the criterion
that it must be helpful for a significant number of people.

Yes, I see some utility in using the compiler to try to
teach people to read the RM, but that is certainly not the
intention of the error messages from GNAT. The intention
is to point out the error in a clear way that allows you
to correct it as easily as possible.

The example you chose seems a case where the GNAT error
message is indeed completely clear from this point of view.

Now if you want to ask the question of where this rule is
in the RM, I agree that a tool of some kind that would lead
to rules can *sometimes* be useful -- I say sometimes
because often the source of the rule is not helpful (of
course in this case 3.8.1 is a complete red herring as I
assume you meant to make clear by your example).

The trouble with putting an RM reference where it is not
needed is that it tends to waste people's time by sending
them off to look at the RM just to check they understand
things.

Let's take this case. The proper reference is of course
3.8(9), and the trouble with this reference is that it is
too course, only the last sentence is interesting:

"The identifiers of all components of a record type shall
 be distinct"

Which provides little or no illumination beyond the
original error message.

Yes, the reference to the last sentence of 3.8(9) is of
value if your specific purpose is to know where a
particular rule came from, but the number of people who
are interested in this is small. Most people just want
to fix their program so it works.

Most certainly I would NOT encourage beginning students
of Ada to spend time reading chapter three of the RM, and
most experts would find the 3.8(9) reference gratuitous
in any case.

I do think it would be nice to have a tool that gave
all sorts of references on error messages to text books,
the RM, the AARM, relevant AI's (perhaps the most important
source of all in practice), etc. And one day maybe there
will be such a tool, but meanwhile, I see little point in
adding RM references in the case of simple rules, where the
error message clearly implies the rule, and the RM does no
more than confirm that the rule exists.

The time that RM references are useful, and the time that
GNAT includes them, is when the rule involved is obscure.
For example:

     1. with Text_IO; use Text_IO;
     2. procedure z is
     3.    type a is record b : integer := 2; end record;
     4.
     5.    x : integer;
     6.
     7.    v : a;
     8.    for v'address use x'address;
               |
        >>> warning: implicit initialization of "v" may
            modify "x", use pragma Import for "v" to
            suppress initialization (RM B(24))

    10. begin
    11.    Put_Line ("Hello");
    12. end;

Now here is a case of a rule which is a surprise to many
expert Ada programmers (especially because it is a new
rule in Ada 95, the above program is of course erroneous
in Ada 83).

It seems quite useful to refer to the RM to explain *why*
we suggest adding the pragma Import. The RM paragraph says:

  24   The declaration of an imported object shall not
       include an explicit initialization expression.
       Default initializations are not performed.

Hopefully these two examples make the viewpoint clear. It
is incidentally often the case that when people have
suggested an RM reference, they choose the wrong place
in the RM. They try, as in the message to which this is
answering, to suggest some helpful general section in the
RM that unfortunately has nothing to do with the case.

Let's take another example. Suppose we write:

   for J in 1 .. 10 loop
     ...
     J := J - 1;
   end loop;

The GNAT message is:

     4.      J := J - 1;
             |
        >>> assignment to loop parameter not allowed

That's pretty clear. Now let's try to give an RM reference.
Well we could reference the note in 5.5(10), but notes are
not part of the standard, and so this is a bit dubious (by
the way, that note is there in the RM because Robert Dewar
complained that otherwise the source of this rule is hard
to find!) The real rule is from 3.3(13):

  13   An object is either a constant object or a variable
       object.  The value of a constant object cannot be
       changed between its initialization and its
       finalization, whereas the value of a variable object
       can be changed. Similarly, a view of an object is
       either a constant or a variable.  All views of a
       constant object are constant.  A constant view of a
       variable objectcannot be used to modify the value of
       the variable.  The terms constant and variable by
       themselves refer to constant and variable views of
       objects.

Here again, we have an overkill problem with a simple
paragraph reference, since it is really only the second
sentence here that is relevant. Note that if we had pointed
to the note, the situation would be even worse, since the
note leads to the *whole* of 3.3, even more overkill.

Of course we also need 3.3(2,6):

  2   All of the following are objects:

      6  a loop parameter;

And of course 3.3(15,19)

  15   Whether a view of an object is constant or variable
       is determined by the definition of the view.  The
       following (and no others) represent constants:

     19  a loop parameter, choice parameter, or entry
         index;

So we could perhaps give as the error message:

>>> assignment to loop parameter not allowed
    (RM 3.3 (2,6,15,19) + 3.3 (13, 2nd sentence)

Now this message would indeed be helpful to the small
minority (probably a larger minority on CLA) of people
who specifically want to answer the question of where
this rule comes from in the RM, but to 99% of the users
of the compiler, the RM references here add nothing at
all since the error message states the rule in a complete
and much more accessible form. Indeed the mumbling about
views in the above references will confuse all but the
most experienced Ada programmers.

This seems the most common case.

Indeed a simple RM reference is almost never sufficient
if your question is "why is this illegal, what exactly
is the RM argument that makes this illegal". Instead you
need an analysis similar to the above. Basically a theorem
must be proved, and the axioms and reasoning for proving
the theorem will involve several RM references.

As I have said before, I see a definite utility in such
a tool for the small number of people who like to nose
around the RM (*), but for most people using the compiler
this tool would not be helpful, and the priority in GNAT
is in working on crafting the error messages so that
neither students nor experts have to run away to the RM
to understand how to fix their programs :-)

Robert Dewar
Ada Core Technologies

(*) if you are an RM explorer, I strongly suggest carefully
reading the AI's that are publicly available. First you
will learn interesting things, second reading these is very
good training in learning how to become a language lawyer
certified as a competent RM reader :-)




















-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[David Peterson]

Robert,

Thankyou for your detailed response to my earlier question regarding GNAT.

In article <79oj1f$e8p$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes:
> In article <F6tqMF.Lz7@syd.csa.com.au>,
>   davidp!nospam!@!nospam!syd.csa.com.au wrote:
> > Dear All,
> >
> > Can anybody tell me if/how it is possible to make the
> > GNAT Ada compiler issue references to the Ada Reference
> > Manual rather than, or in addition to, the regular error
> > messages issued by the compiler ?
> 
> > I know that other Ada compilers such as Vertix and VADS
> > can do this
> 
> Actually the latter are the wrong comparison points, since
> these are Ada 83 compilers, and in our view the situation
> with Ada 95 is quite different from Ada 83.
> 

That is an interesting perspective. I have always considered Ada 95 as a
superset and extension of Ada 83 (with improvements and fixes), rather than
as a *new* language per se. With so much of the language common between the
two variants, I didn't consider the comparison of two Ada compilers (one 83,
the other 95) on features not related to Ada 95 language issues to be "wrong" or
unfair.

I was making the comparison on the basis of limited experience with Ada compilers
with which I am familiar.

> We only give Ada 95 RM references in rare cases where they
> are actually helpful. In our experience, most of the time
> if a well thought out error message is not clear to a user,
> then they probably do not have the level of knowledge
> necessary to benefit from going to the reference manual.
> 

Hmmm ... I thought that the rationale should be that if an error message is not
clear, you should be able to reference some document to clarify the situation.

The solution above assumes that all error messages are clear and well thought out
(which may be true!), and that all the required information can be communicated in
1-2 lines of console output (which I find hard to believe).

Also, I think that the majority of people developing software in Ada *do* have the
intellectual capability and educational background to read the reference manual,
which might not be the case in other languages such as C / C++ (a more diverse
user base).


> We prefer to work on making the error messages as clear as
> possible to someone who is NOT a language expert and NOT
> comfortable reading the reference manual. That is the goal.
> 
[cut]

I certainly accept that, and find GNAT a great compiler to work with. The error
messages are clear and concise. However, I do believe that the majority of people
developing software in Ada are serious enough programmers to be comfortable
reading (or at least attempting to read !) the ARM. 


> 
> We do NOT think that adding RM references would help in
> the goal of continued improvement of GNAT messages.
> 
> 

My only comment would be that the addition of a switch or option to toggle the
issuing of ARM references in addition to the current set of comments would
add flexibility. Those that wished to obtain additional information regarding
an error could toggle the option, with the compiler responding with the additional
information as required.

I agree that in general ARM references can clutter up the error output, and that
well thought out "plain english" messages are often preferable to ARM text - but
surely access to both would be the best solution ?

Again, thanks for your time and comments, and for answering my original question
regarding the availability of such a feature in GNAT.

Just thought I'd add a few comments (above), but I am certainly not inclined to
tread old ground over and over, nor to start a "holy war" on the issue of comments
in GNAT ! :-) It's a good compiler, and I'll take it as it comes ...

Regards,



David Peterson

Re: Getting GNAT to issue ARM error messages

[Larry Kilgallen]

In article <F6xCoB.Cny@syd.csa.com.au>, davidp!nospam!@!nospam!syd.csa.com.au (David Peterson) writes:

> In article <79oj1f$e8p$1@nnrp1.dejanews.com>, robert_dewar@my-dejanews.com writes:
>> In article <F6tqMF.Lz7@syd.csa.com.au>,
>>   davidp!nospam!@!nospam!syd.csa.com.au wrote:
>> > Dear All,
>> >
>> > Can anybody tell me if/how it is possible to make the
>> > GNAT Ada compiler issue references to the Ada Reference
>> > Manual rather than, or in addition to, the regular error
>> > messages issued by the compiler ?
>> 
>> > I know that other Ada compilers such as Vertix and VADS
>> > can do this
>> 
>> Actually the latter are the wrong comparison points, since
>> these are Ada 83 compilers, and in our view the situation
>> with Ada 95 is quite different from Ada 83.
>> 
> 
> That is an interesting perspective. I have always considered Ada 95 as a
> superset and extension of Ada 83 (with improvements and fixes), rather than
> as a *new* language per se. With so much of the language common between the
> two variants, I didn't consider the comparison of two Ada compilers (one 83,
> the other 95) on features not related to Ada 95 language issues to be "wrong" or
> unfair.

Robert's point is not that the two generations of the Ada language
are so different, but that the Reference Manuals for those are so
different.  While a compiler referring a newcomer to a page in the
Ada83 reference manual is quite helpful, a compiler referring a 
newcomer to a page in the Ada95 reference manual could lead to
confusion because of the way that book is written.

Larry Kilgallen

Re: Getting GNAT to issue ARM error messages

[dewar]

In article <1999Feb10.073547.1@eisner>,
  Kilgallen@eisner.decus.org.nospam wrote:

> A compiler referring a
> newcomer to a page in the Ada95 reference manual could
> lead to confusion because of the way that book is
> written.


And just to clarify what Larry wrote above, this is not
in any way a criticism of the ADa 95 RM, just a comment
on its different stylistic approach. Clarity for
non-experts and precision for experts are often opposing
goals. There are several factors in this opposition:

1. Precision for experts usually requires a more formal
style that is less accessible for non-experts.

2. Precision requires considering marginal cases carefully
and thoroughly that may confuse non-experts.

3. Redundancy, that is so often helpful in explaining
things to non-experts, is a menace in a precise definition,
it can only lead to self-contradiction, and adds nothing.

4. In a formal definition, precise terminology, and the
style of depending on that terminology is an important
tool, but it can often confuse (an example: how many
non-expert users immediately understand that a generic
package is not a package, so a rule that applies to
packages does not [necessarily] apply to generic packages).

The viewpoint of the designers of Ada 95 was that the Ada
83 reference manual was insufficiently precise, and that a
more formal, more precise approach was desirable. This was
a controversial point, and remains moot (undecided and
arguable) in my opinion, but that's a separate issue from
the current one (whether to put RM references in messages).

One thing to remember here is that I was the one who
started the idea of putting RM references in messages. The
first compiler to do this was Ada/Ed, and at the time it
was an innovation. I am not aware of previous compilers for
other languages that contained references to the standard
in this manner (after all most programmers for other
languages don't even know a standard exists, let alone use
it as a standard reference source). Other Ada 83 compilers
copied this innovation from Ada/Ed.

So I certainly don't oppose the general idea, and indeed
the general idea is a good one, *if* the standard is
written in an aggressively accessible style. For the Ada
83 standard, I think this criterion was usually met. For
the Ada 95 standard, it makes better sense to decide on
a case by case basis if an RM reference is helpful.

That is why my suggestion is to consider individual
examples where an RM reference would be helpful, rather
than discussing the point as a general abstract issue.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Tucker Taft]

dewar@gnat.com wrote:
> 
> That is why my suggestion is to consider individual
> examples where an RM reference would be helpful, rather
> than discussing the point as a general abstract issue.

For what it is worth, we took an opposite view with AdaMagic, namely
that we try to provide a starting point in the RM for every
error message we give (though sometimes we give up).

This of course may relate to the fact that we are closely
affiliated with the primary authors of the RM ;-).
I think it also serves to help the user learn their
way around the RM, which is admittedly heavy going.

But in any case, vive la difference!  Competition is
a great way to have various approaches available out there.
Certainly GNAT has many excellent error messages, and certainly
we have many RM references.  Personally, I wish we had
the best of both ;-), and I suspect all compilers are in fact
converging on better error messages, and judicious use of RM
references.  Specific user suggestions are always welcome (though
instant response is not always possible, unfortunately ;-).

> Robert Dewar
> Ada Core Technologies

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Getting GNAT to issue ARM error messages

[Nick Roberts]

It seems to me that Robert Dewar's argument is false, really. He seems to be
arguing, in essence, that "because it will help very few users, GNAT should
not issue references (to the RM95)". But, surely, if the references would
help any user at all (e.g. me), they should be included. How could they do
any harm?

I would happily agree that such references should (almost) never be
considered a replacement for a good error message, but only as a supplement.

Incidentally, I intend this more as a suggestion than a criticism. [There
are many other things one might suppose a compiler 'ought to do'. Some
particularly exacting programmers might fully expect their compiler to quote
the RM95 fully, as well as correcting their source code in-place
automatically, updating a central repository of programmers' typical
mistakes and associated corrections, telling a few jokes, and making the
coffee. Criticism is easy.]

-------------------------------------------
Nick Roberts    "The Prophylactic Didactic"
-------------------------------------------

Re: Getting GNAT to issue ARM error messages

[bill]

In article <7a490k$snr$1@plug.news.pipex.net>, "Nick says...
 
I agree it will be nice to have an RM reference if possible added to the
error message. as you said, if someone wants to use it, it is there.

Bill

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

In article <7a490k$snr$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:
> It seems to me that Robert Dewar's argument is false,
> really. He seems to be arguing, in essence, that "because
> it will help very few users, GNAT should not issue
> references (to the RM95)". But, surely, if the references
> would help any user at all (e.g. me), they should be
> included. How could they do any harm?

First of all, most *certainly* useless RM references have
the potential for harm. They can send people off on wild
goose chases trying to read (to them) incomprehensible
stuff in the RM which just adds confusion to lack of
understanding.

Once again, the GNAT philosophy is to include the RM
reference if and only if it is significantly helpful to
the majority of users.

We do not find many such examples!

The argument that extra information should be supplied in
an error message even if it is only useful to a very small
number of users is dubious. It would for example equally
well justify routinely adding a Russian translation of the
message, along with a dubious RM reference.

Once again, how about a specific example where an RM
reference would help general users.

Nick, you are writing an Ada compiler, that means you know
the RM backwards and forwards and completely (or you don't
have a chance), so you are definitely NOT the kind of
person to whom the error messages are targetted (indeed I
would think anyone knowing the RM that well would not in
any case need RM references :-)

Robert Dewar
Ada Core Technologis

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Nick Roberts]

robert_dewar@my-dejanews.com wrote in message
<7a5b71$d25$1@nnrp1.dejanews.com>...
[...]
|First of all, most *certainly* useless RM references have
|the potential for harm. They can send people off on wild
|goose chases trying to read (to them) incomprehensible
|stuff in the RM which just adds confusion to lack of
|understanding.


Couldn't you just warn users in the GNAT manual not to follow RM references
unless they are Ada experts? (On reflection, I think I can see the answer to
this one: how many users read the manual? :-)

|Once again, the GNAT philosophy is to include the RM
|reference if and only if it is significantly helpful to
|the majority of users.
|

|We do not find many such examples!

This might argue for the inclusion of a compiler flag (do as GNAT now does
by default, but a flag ('-smartass'?) causes references to be added). But,
I'll admit, this might be considered just a tad overkill!

|The argument that extra information should be supplied in
|an error message even if it is only useful to a very small
|number of users is dubious. It would for example equally
|well justify routinely adding a Russian translation of the
|message, along with a dubious RM reference.


A very fair point (badly put :-)[supplying versions of an application
program (and in this sense a compiler is an application program) for
different (human) languages is hard work but usually a worthy exercise].
Plainly, an error message which ran on for seven pages, and included amusing
anecdotes on the relevant subject plus a full horoscope, is unlikely to be
what any user would want.

|Once again, how about a specific example where an RM
|reference would help general users.


Well I (personally) have to admit to being stumped by this one, for the
simple reason that I am not a GNAT user (yet)[I may become a GNAT user in
the future, depending on various things]. I can only report that I myself
have always appreciated those compilers which gave out references to the
approriate sections in their respective manuals. However, I have to admit
that this is not entirely a fair comparison, since the RM95 is not any
compiler's manual (or at least shouldn't be), and I guess I am not a typical
user anyway.

|Nick, you are writing an Ada compiler, that means you know
|the RM backwards and forwards and completely (or you don't
|have a chance), so you are definitely NOT the kind of
|person to whom the error messages are targetted

Point accepted.

Actually, since I am considering using the well-worn trick of putting all my
error messages into a big text file (precisely to make it easier to supply
multi-language versions by simply supplying different message files with the
same compiler), it occurs to me that supplying different versions of the
messages file aimed at different kinds of user could be a practical
possibility.

The problem with this approach, of course, is that, for most compilers,
reading in a big text file every time one compiles is likely to be
unacceptably slow. [OTOH I have the luxury: I'm not actually going to worry
about compiler speed myself (it's not going to be a commercial program).]

However, a variation of this trick might be to factor the messages out into
a separate package (or hierarchy) which simply contained a list of constant
string declarations. [Does GNAT already do this? I shall be downloading the
GNAT sources soon, in fact.]

|(indeed I
|would think anyone knowing the RM that well would not in
|any case need RM references :-)

Still studying like crazy ;-)

|Robert Dewar
|Ada Core Technologis


Nick

Re: Getting GNAT to issue ARM error messages

[dewar]

In article <7a7aat$mse$1@plug.news.pipex.net>,
  "Nick Roberts" <Nick.Roberts@dial.pipex.com> wrote:

> Well I (personally) have to admit to being stumped by
> this one, for the simple reason that I am not a GNAT user
> (yet)[I may become a GNAT user in the future, depending
> on various things]. I can only report that I myself have
> always appreciated those compilers which gave out
> references to the approriate sections in their respective
> manuals. However, I have to admit that this is not
> entirely a fair comparison, since the RM95 is not any
> compiler's manual (or at least shouldn't be)

It sure is fascinating for you to argue energetically
that adding RM references to messages you
have never seen must be a good idea because adding
completely different kinds of references to messages from
a completely different compiler was helpful to you :-)

Actually I nearly always find that people arguing that RM
references should be added are arguing from a general sense
of what makes common sense to them, rather than actual
difficulty in interpreting RM references. The one case I
have seen of people arguing for an RM references is experts
who are sure they know the language better than GNAT :-)
They want an RM reference not to explain the error, but
to convince themselves that GNAT is right!

So let me state once again the philosophy of GNAT. It is
to provide RM references if and only if they seem useful
to typical users of the compiler.

It is hard to believe that anyone could disagree with this
general principle. I can imagine that people might disagree
with the judgment in a particular instance, which is why
I encourage people to send us examples (to report@gnat.com)
where they think an error message is not clear, and to
suggest improvements -- people do that all the time,
although I must say, no one ever suggested adding a
specific RM reference!

So Nick, wait till you have some experience with the
subject under discussion. Remember that GNAT has put a
HUGE amount of effort into generating clear error messages,
and handles many error situations far better than other
compilers (e.g. proper dealing with the confusion of IS
and semicolon in subprogram specs and bodies).

You need to use GNAT before you are in a position to
make comments on what might or might not make its error
messages clearer I think!

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Ehud Lamm]

On Mon, 15 Feb 1999 dewar@gnat.com wrote:

> So let me state once again the philosophy of GNAT. It is
> to provide RM references if and only if they seem useful
> to typical users of the compiler.
> 

This must be the right approach, and GNAT is a very good compiler - and so
are the error messages. 

However, there's one thing I think important to think about. GNAT is used
heaviliy for education. I think a part of really learning Ada, is being
able to at list follow the general description of the RM, even if not
grasp all the details. In this, I think, the compiler can help - by point
the programmer to the RM. 

It is true that this was much nicer in Ada83, but I still think that in
many cases the RM is readable - esp. when you have hypertext referecnes to
definitions.

I don't think it is a must, and I don't think this is really high
priority. However since the discussion got the point where "typical users"
were concerned, I'd thought I'd mention this viewpoint.

Ehud Lamm     mslamm@pluto.mscc.huji.ac.il

Re: Getting GNAT to issue ARM error messages

[steve quinlan]

You will never change Robert's mind on this. To my mind the flaw is in
thinking that a bunch of Ada experts can determine whether in  any given case
users (which users?)  would find RM references useful. I don't think they can
reliably.

I had this same argument with him when I was doing a compiler trade study (we
picked GNAT anyway, but this did get counted against it). Even if we can't
change his mind, the fact that overwhelmingly users want this seems like it
should move ACT to be more responsive. But they know best what we need to
correct our errors. (;-)

Yes, their "hey, dummy, didn't you really mean to .." messages are great. I
guess I would even bend on insisting that  every error message would need an
RM reference. But, at at least the ones where there is no "hey, dummy" message
-- if the compiler  can't tell me how to fix the error, then it ought to tell
me which rule I violated.

I think I do remember him agreeing that the error messages should use relevant
RM terminology. If they do, then at least a text search of the RM could
potentially get you to relevant sections. But, not everyone may have a
searchable version. The HTML isn't easily searchable. There is a plain text
version which can be searched I guess.

Re: Getting GNAT to issue ARM error messages

[Steve Whalen]

steve quinlan <steven.quinlan@lmco.com> wrote:
: You will never change Robert's mind on this. To my mind the flaw is in
: thinking that a bunch of Ada experts can determine whether in  any given case
: users (which users?)  would find RM references useful. I don't think they can
: reliably.
[snip]
: change his mind, the fact that overwhelmingly users want this seems like it
: should move ACT to be more responsive. But they know best what we need to
: correct our errors. (;-)
[snip]

The "fact" that "... overwhelmingly users want this ..."?  Speak for
yourself.

One major reason I would NOT want RM references or other annotations
on every error message, is that 80%+ of the time, I just need a brief
reminder of what it was that I did that was stupid, or inattentive.
Extra verbage would just distract me and slow me down.

When I _do_ need help understanding where I did something more
seriously wrong, I'd want more than an RM reference.

What I'd _wish_ for, is to have the compiler display a carefully
researched reference to the _best_ place to learn more about whatever
I've gotten wrong.

So if the best description of how to do "whatever I'm confused about"
is in Prof. Feldman's Ada95 book in chapter XX, I'd _like_ to see a
pointer to that book and chapter, or to the Ada83 RM, or a web page,
etc.

Since what I want does NOT exist, I'm not going to complain about it
until I'm willing to do (or fund) the work myself.

Steve
-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Getting GNAT to issue ARM error messages

[Pascal Obry]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

steve quinlan a �crit dans le message <36C9C0BC.EA9C114E@lmco.com>...
>You will never change Robert's mind on this. To my mind the flaw is in
>thinking that a bunch of Ada experts can determine whether in  any given
case
>users (which users?)  would find RM references useful. I don't think they
can
>reliably.
>
>I had this same argument with him when I was doing a compiler trade study
(we
>picked GNAT anyway, but this did get counted against it). Even if we can't
>change his mind, the fact that overwhelmingly users want this seems like it
>should move ACT to be more responsive. But they know best what we need to
>correct our errors. (;-)
>


The good news is that you can download GNAT sources and add this feature
yourself :-)

Pascal.

Re: Getting GNAT to issue ARM error messages

[Jean-Pierre Rosen]

steve quinlan a �crit dans le message <36C9C0BC.EA9C114E@lmco.com>...
>I think I do remember him agreeing that the error messages should use
relevant
>RM terminology.
THIS is a real issue. For example, my experience is that the term
"subtype mark" is very confusing to beginners. I always have to
explain that it means "the name of something that is a (sub)type".
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

In article <7af1kj$pm7$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> steve quinlan a �crit dans le message
<36C9C0BC.EA9C114E@lmco.com>...
> >I think I do remember him agreeing that the error
> >messages should use relevant RM terminology.

> THIS is a real issue. For example, my experience is that
> the term "subtype mark" is very confusing to beginners. I
> always have to explain that it means "the name of
> something that is a (sub)type".

I actually agree with JPR here, despite Steve's memory of
my agreeing to the contrary :-)

RM terminology, especially in RM 95, can often be quite
confusing, for example the value of a variable does not
include the tag, but an error message that depended on
the reader knowing the the use of the word "value" excluded
the tag, where this was critical to understanding, would
likely be confusing.

Similarly, a message that depended on the user knowing that
the term package excludes generic package could also be
confusing.

Almost everyone thinks of a package as having a spec and
a body, and insisting dogmatically on using package
declaration and subprogram declaration in all messages
might well be confusing.

Another example of terminology that could be confusing is
nominal subtype.

Actually what is really needed in some of the error
situations is not just a magic RM reference, or some
magic RM terminology to make things clear, but a long
and extended tutorial on a delicate point in the language.
I often write these tutorials, both here on CLA, and for
our customers! Elaboration issues for example are a
particularly tricky area.

Our vision for error messages is a tool for which we have
a nice name GNOME (GNat Online Message Explanation). The
idea is that you click on a message, and you get all kinds
of extra stuff, extra explanations, multiple RM references
with an explanation of how they apply (RM references
without this explanation are typically of limited value),
references to the Rationale, the AARM, and even to Ada text
books.

Unfortunately, the only thing that exists about this tool
right now is the name :-)

Actually in our experience, relatively few error messages
cause significant confusion at this stage (some of them are
ones for which we already have RM references, but they
still cause confusion!)


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Keith Thompson]

robert_dewar@my-dejanews.com writes:
> Our vision for error messages is a tool for which we have
> a nice name GNOME (GNat Online Message Explanation). The
> idea is that you click on a message, and you get all kinds
> of extra stuff, extra explanations, multiple RM references
> with an explanation of how they apply (RM references
> without this explanation are typically of limited value),
> references to the Rationale, the AARM, and even to Ada text
> books.
> 
> Unfortunately, the only thing that exists about this tool
> right now is the name :-)

Unfortunately, you don't even have that, unless you really want to
confuse people.  The name GNOME is already being used for the GNU GUI
desktop project.  (It's bad enough that the GNU bug tracking system is
called GNATS.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com <*>
San Diego, California, USA <http://www.ghoti.net/~kst>
Will write code for food.

Re: Getting GNAT to issue ARM error messages

[dennison]

In article <yec1zjny0ri.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> robert_dewar@my-dejanews.com writes:
> > Our vision for error messages is a tool for which we have
> > a nice name GNOME (GNat Online Message Explanation). The
> > idea is that you click on a message, and you get all kinds
> > of extra stuff, extra explanations, multiple RM references
> > with an explanation of how they apply (RM references
> > without this explanation are typically of limited value),
> > references to the Rationale, the AARM, and even to Ada text
> > books.
> >
> > Unfortunately, the only thing that exists about this tool
> > right now is the name :-)
>
> Unfortunately, you don't even have that, unless you really want to
> confuse people.  The name GNOME is already being used for the GNU GUI
> desktop project.  (It's bad enough that the GNU bug tracking system is
> called GNATS.)

How about "Integrated GNat Online Blooper Listing Enviroment" (IGNOBLE)?





T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Chris Morgan]

dennison@telepath.com writes:

> How about "Integrated GNat Online Blooper Listing Enviroment" (IGNOBLE)?

In that case the tool which only gave you RM references would be the
Integrated GNat Official RANT.
-- 
Chris Morgan <mihalis at ix.netcom.com                http://mihalis.net

Re: Getting GNAT to issue ARM error messages

[David Brown]

Keith Thompson <kst@cts.com> writes:

> robert_dewar@my-dejanews.com writes:
> > a nice name GNOME (GNat Online Message Explanation). The
> > 
> > Unfortunately, the only thing that exists about this tool
> > right now is the name :-)
> 
> Unfortunately, you don't even have that, unless you really want to
> confuse people.  The name GNOME is already being used for the GNU GUI
> desktop project.  (It's bad enough that the GNU bug tracking system is
> called GNATS.)

There's also GLADE and GLADE.  There's the GNAT Library for Ada
Distributed Execution.  GLADE is also a GUI builder program being
developed for Gtk+.  What makes it even more exciting is that the GUI
GLADE is getting support for Ada as well.

So I want GNOME running under GNOME developed with GLADE and using
GLADE to get the information.  Whew.

Dave Brown
dlbrown@acm.org

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

In article <yec1zjny0ri.fsf@king.cts.com>,
> Unfortunately, you don't even have that, unless you
> really want to confuse people.  The name GNOME is already
> being used for the GNU GUI desktop project.  (It's bad
> enough that the GNU bug tracking system is called GNATS.)

Ada folks can handle a bit of overloading :-)

Note that we have had zero trouble in practice from the
GNAT/GNATS clash (we were there first on that name, but
no big deal!)

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[dewar]

In article <36C9C0BC.EA9C114E@lmco.com>,
  steve quinlan <steven.quinlan@lmco.com> wrote:
> I had this same argument with him when I was doing a
> compiler trade study (we picked GNAT anyway, but this did
> get counted against it). Even if we can't change his
> mind, the fact that overwhelmingly users want this seems
> like it should move ACT to be more responsive. But they
> know best what we need to correct our errors. (;-)

Well Steve, you still have not sent in ONE specific
suggestion. I actually think almost NO one agrees that
ALL messages should have RM references, and in fact it
is not at all clear that "overwhelmingly users want this"
at all. Most users find the error messages in GNAT to be
one of its strong points, and in most trade comparisons
that have been done, GNAT comes out ahead on quality of
error messages.

So I don't think there is by any means general support for
including RM references in all messages.

Consequently, I think we agree that the idea is to have
RM references where they are helpful. Note that Tuck seemed
to suggest that he agrees with this as well, even though in
the past the Intermetrics front end, following the
tradition that I established many years ago in Ada 83 with
Ada/Ed, the first compiler to do this, does put RM
references in all messages, many of them, in my opinion,
and in the opinion of many others, gratuitous (if you have
a missing semicolon, it is plain idiotic to give an RM
reference, and it does not matter whether or not you
are an Ada expert to agree with that :-)

Now in the current thread, one of the strong arguers for
RM references admitted that he did not know the Ada 95 RM
well and had never used GNAT, so could not give any
specific examples.

Well you have used GNAT, how about making some specific
suggestions about error messages where you think a specific
RM reference would be helpful. It is striking that we still
have never received even ONE such suggestion, and goodness
knows we receive loads of suggestions about all sorts of
other things!

As for using RM terminology, we actually found that the
majority of complaints about error messages being obscure
(we get many such complaints/suggestions, see one of them
below), were to do with the use of less well known RM
terms, and we greatly improved the messages (in the opinion
of those submitting the reports) by reverting to plain
language. For example, an error message that critically
depends on knowing what accessibility means is likely to
confuse (and just try finding an RM reference to
elucidate). Another good example is the case of:

  procedure q is
     type r is access all string;
     m : aliased string (1 .. 3) := "CAT";
     z : r := m'access;
  begin
     null;
  end q;

Now the error message we used to give was simply:

     4.    z : r := m'access;
                    |
        >>> object subtype must statically match designated
            subtype

This uses RM terminology, and the appropriate RM reference
would be presumably RM 3.10.2(27)

  27  If the designated type of A is tagged, then the
      type of the view shall be covered by the
      designated type; if A's designated type is not
      tagged, then the type of the view shall be the
      same, and either A's designated subtype shall
      statically match the nominal subtype of the view,
      or the designated subtype shall be discriminated
      and unconstrained;

Well I am sure that is a *big* help to someone completely
puzzled by the error message. This is incidentally a VERY
common case to get confused over, most people have no idea
why the above program should be illegal. So we added some
warnings (which only come out if you make this error):

     3.    m : aliased string (1 .. 3) := "CAT";
           |
        >>> warning: aliased object has explicit bounds
        >>> warning: declare with explicit initialization
        >>> warning: for use with unconstrained access

Now things are much clearer, and the compiler tells you
how to fix things. Since we put these warnings in, we have
not had one person ask us about this message.

That example should I think give a bit better idea of our
error message philosophy, which is to give sufficient
information for people to fix their programs with a minimum
of effort.

I personally think that nearly *any* reference to chapter 3
of the RM is likely to be unhelpful -- well of course that
is a bit strong, but most of chapter 3 is extremely
difficult to follow.

I think we can all agree that the main purpose of error
messages is to point people quickly to the error they have
made and let them fix it. At the same time, hopefully they
learn the general principle (note that the warnings above
do state the general principle, and they state it in a
clear form which you simply cannot find ANYWHERE in the RM.
Indeed this particular rule is a consequence of several
rather strange (and probably unfortunate) decisions made
in the Ada 95 design. Deducing the substance of those
warning messages, let alone motivating them, from the RM,
is quite a tough job.

But anyway the challenge stands, point to particular error
messages where an RM reference is useful. I can certainly
do so, since we include RM references in quite a number of
messages, here are some examples:

   private function with tagged result must override
   visible-part function move subprogram to the visible
   part (RM 3.9.3(10))

   exception "..." is declared in generic formal package
   and therefore cannot appear in handler (RM 11.2(8))

Now how about the "overwhelming majority of users who like
RM references" suggest some other useful places to add
RM references to GNAT messages, and suggest the actual rule
that is helpful.

Steve mentions that compiler experts may have trouble
coming up with useful messages. I definitely agree, and
indeed I think that adding unhelpful RM references is an
*instance* of this happening. Someone who understands the
RM very well may well see why some apparently irrelevant
clause in the RM is indeed the reason for the compiler
finding the error, but just remember that even if this is
the case, it may still be completely confusing, because the
compiler does NOT know what the programmer had in mind.
This is just a guessing game.

Surely no one thinks that RM references should be supplied
when they are unhelpful, and most CERTAINLY no one takes
the attitude that RM references are unhelpful in all cases.
So there is really no philosophical differences. I am not
sure if you trade study unearthed any specific examples
where he thought GNAT made the wrong choice of whether or
not to include an RM reference, but if so, you sure did
not tell us about them :-)

You talk about it being "difficult to change my mind", but
that is a bit puzzling. What are you trying to change my
mind to? To agree that ALL error messages should have RM
references? Even Tuck does not seem to believe that :-)
To add more RM references? Well that's not a useful goal
of itself unless they are useful. To add more useful
RM refereces? No problem, I agree that we should add more
useful RM references if we can identify them. We have
identified those that we felt were most obviously cases
where RM references helped.

Please help us locate others!

Robert Dewar
Ada Core Technologies












-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[steve quinlan]

Actually, the "statically matching" error message you gave was the one in
GNAT at the time I was doing the trade study. My questions to you on that
point   led to your changing that message, I believe, as well as to the
exchange we had at the time about RM references in error messages. Do you
recall this?  Is your new message better? Yes. I don't maintain that ONLY
RM sections should be given in error messages. Take your best shot at
giving the user a way to fix the problem. Then, in parens, you could give
the RM reference for non-trivial errors.

The problem with adding such references onesy-twosy as you find them to be
useful is that no one is using the FUTURE version of the compiler, where
that reference will be added after you've decided it would be useful to add
it. It's always today's version, where that reference is not there, which
is in use.

Where I miss such references most is not when I've made some stupid syntax
error, or a trivial semantic error, but when I've violated some limitation
of Ada, as in the "statically matching" example. Certainly I like to be
told what to do to fix my error, but I also would like to understand why I
can't do what I thought I could. Maybe there are related issues to  that
particular error that a  reading of the RM on that topic will raise. The
rule about statically matching subtypes is such an arcane rule. It's so
bizare, that besides upgrading your text error message, I would have argued
for putting in an RM reference as well on that one.  As long as you were in
there changing the message, what could it have hurt to put "RM 3.10.2(27)"
in parentheses?

I was taken to task by several for claiming that the overwhelming number of
users would want full, or nearly full, RM references. Of course, I have no
survey to go on. I would love to take one. Anyone who wants to send me
their opinion can do so. The question would be : "would you like to see RM
section references in compiler error messages (in addition to the BEST,
MOST INSTRUCTIVE text message) for non-trivial errors? Trivial would be
syntax errors and semantic errors that are almost of the same class as dumb
syntax mistakes -- trying to assign a string variable to an  integer, stuff
like that. I will tablulate and post the results. Of course, it would be an
unscientific, self-selecting sample so it will have only an entertainment
value, right Robert?  (;-)

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

In article <36CAE459.EFE2A7E7@lmco.com>,
  steve quinlan <steven.quinlan@lmco.com> wrote:
> Actually, the "statically matching" error message you
> gave was the one in GNAT at the time I was doing the
> trade study. My questions to you on that point   led to
> your changing that message, I believe, as well as to the
> exchange we had at the time about RM references in error
> messages. Do you recall this?  Is your new message
> better? Yes. I don't maintain that ONLY RM sections
> should be given in error messages. Take your best shot at
> giving the user a way to fix the problem. Then, in
> parens, you could give the RM reference for non-trivial
> errors.

But that's the point Steve! I can't figure out a useful
RM reference for this particular message, can you? If so
please let me know and make the suggestion. We certainly
don't want to start putting random RM unhelpful RM
references in to make people feel better! So take this
particular example as a challenge, find a relevant useful
RM reference for this message.
>
> The problem with adding such references onesy-twosy as
> you find them to be useful is that no one is using the
> FUTURE version of the compiler, where that reference will
> be added after you've decided it would be useful to add
> it.

No, we add the RM references as we go along (all the
current RM references in GNAT are ones that *we* decided
are useful -- as I mentioned no one has ever made a
suggestion to us to add a specific RM reference). We add
an RM reference whenever we think it is useful. If you
are asking us to do more than that, you are asking us to
add RM references that in our judgment are misleading and
unhelpful. That doesn't seem a good idea!

> Where I miss such references most is not when I've made
> some stupid syntax error, or a trivial semantic error,
> but when I've violated some limitation of Ada, as in the
> "statically matching" example.

Great, so please reveal the RM reference that you missed
in this particular case.

My feeling here is that the rule about static matching is
quite obvious, and referring to the RM reference that says
static matching is required would not help you find your
error here. The problem is the rather obscure set of rules
that together lead to the unexpected fact that this is
indeed a surprising case of lack of static matching.

> The rule about statically matching subtypes is such an
> arcane rule.

Actually it is not, it is a perfectly straightforward rule.
It is not the requirement for static matching that puzzles
people here, since that is an obvious implementation
requirement, it is the fact that the two declarations:

   A : aliased string (1 .. 3) := "abc";
   B : aliased string          := "abc";

are so radically different in effect.

> What could it have hurt to put "RM 3.10.2(27)"
> in parentheses?

It would hurt because it would not help. I cannot imagine
anyone who could not understand the original error message
and would be enlightened by this particular reference,
since it has nothing at all to do with the real error,
which has to do with the difference between the above
two error messages.

So what you do here for virtually all users is to give them
a message they do not understand, and then send them off to
the RM to read a paragraph that is not in the least bit
useful, but which you have claimed is useful. This is not
just annoying but misleading. The error message would be
saying, think about the rule in 3.10.2(27), but that will
*decrease* the likelihood of finding the error, not
increase it I am afraid, since it misdirects the user to
the wrong consideration.

THe warnings we output are likely to be FAR more useful for
a user to understand what is going on. Even for these
warnings, it is not at all easy to give a useful RM
reference.

> It would be an unscientific, self-selecting sample so it
> will have only an entertainment value, right Robert?
(;-)

Well as we have seen there are people who strongly support
this even though they are unfamiliar with GNAT and
unfamiliar with the RM, so yes, it certainly cannot have
more than entertainment value.

What is most remarkable in this thread is that not ONE
person has made a specific suggestion of a specific RM
reference they would like to see added to a message. I
find this suprising. Surely if this is such a problem,
you must have a case where you have thought, gee! if only
GNAT had pointed me to section ???? of the RM, everything
would have been clearer.

I am really disappointed that this conversation remains at
the general level, and has not resulted in even ONE useful
constructive suggestion for adding a useful RM reference.
Surely there must be some examples. Please send them along
to report@gnat.com (and by all means post them here for
our instruction :-)

P.S. I do not count you sending back to me the suggestion
of 3.10.2(27), since this was an example I specifically
gave of an RM reference that is obviously NOT helpful.

So, how about it, anyone have even ONE example. If you are
using Object Ada, surely there is ONE case in which you
liked the OA message better because it gave you a useful
RM reference.

Indeed if it is really true that universal RM references
are helpful, any user of these two compilers should have
hundreds of such examples at hand!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Simon Wright]

dewar@gnat.com writes:

>      3.    m : aliased string (1 .. 3) := "CAT";
>            |
>         >>> warning: aliased object has explicit bounds
>         >>> warning: declare with explicit initialization
>         >>> warning: for use with unconstrained access
> 
> Now things are much clearer, and the compiler tells you
> how to fix things. Since we put these warnings in, we have
> not had one person ask us about this message.

It still takes me more than a few looks at this to determine that you
want me to write

  m : aliased string := "CAT";

because the original has what looks very like explicit initialization!
(or is 'explicit' a technical term here?)

Re: Getting GNAT to issue ARM error messages

[Jerry van Dijk]

Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:

: This might argue for the inclusion of a compiler flag (do as GNAT now does
: by default, but a flag ('-smartass'?) causes references to be added). But,
: I'll admit, this might be considered just a tad overkill!

Hmmmm, how about overloading the standard gcc '-pedantic' flag...

:-)

--
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | jdijk@acm.org
-- see http://stad.dsl.nl/~jvandyk

Re: Getting GNAT to issue ARM error messages

[dennison]

In article <F766FJ.8n@jvdsys.stuyts.nl>,
  jerry@jvdsys.stuyts.nl (Jerry van Dijk) wrote:
> Nick Roberts (Nick.Roberts@dial.pipex.com) wrote:
>
> : This might argue for the inclusion of a compiler flag (do as GNAT now does
> : by default, but a flag ('-smartass'?) causes references to be added). But,
> : I'll admit, this might be considered just a tad overkill!
>
> Hmmmm, how about overloading the standard gcc '-pedantic' flag...
>
> :-)

I can just see my coworkers' reactions when they see me compiling with "gcc -c
-g -pedantic -smartass"
:-)

T.E.D.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[Alexy V Khrabrov]

Jerry van Dijk wrote in message ...
>Hmmmm, how about overloading the standard gcc '-pedantic' flag...


How about making that flag switch the compilation from C++ to Ada?
That's what real pedantic is!

>-- Jerry van Dijk | Leiden, Holland
>-- Team Ada       | jdijk@acm.org
>-- see http://stad.dsl.nl/~jvandyk

Cheers,
Alexy

Re: Getting GNAT to issue ARM error messages

[robert_dewar]

In article <36C47579.3D0CAFCB@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> Personally, I wish we had
> the best of both ;-), and I suspect all compilers are in
> fact converging on better error messages, and judicious
> use of RM references.

Just to be absolutely clear, the GNAT philosophy is to add
RM references wherever they are helpful. However, we have
not found very many such cases!

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: Getting GNAT to issue ARM error messages

[dewar]

In article <F6xCoB.Cny@syd.csa.com.au>,
  davidp!nospam!@!nospam!syd.csa.com.au wrote:
> Also, I think that the majority of people developing
> software in Ada *do* have the intellectual capability and
> educational background to read the reference manual,
> which might not be the case in other languages such as C
> C++ (a more diverse
> user base).

I wonder how intimately familiar you are with the Ada 95
RM. It is a VERY difficult document to read in many places,
as I believe is pretty much inevitable if you aim for a
very high level of near-formal precision. Try for example
to understand the accessibility rules from the RM. Very few
people can easily read this material. I speak as someone
who *is* very familiar with the Ada 95 RM.

Note that for me, the situation is totally different
between the Ada 83 and Ada 95 manuals. I often find that
people who want RM references are working from Ada 83
experience, and thinking in terms of the Ada 83 reference
manual.

The kind of people who can successfully read the RM are
generally exactly the kind of people for whom the GNAT
messages should be immediately sufficient. Yes, there are
a few cases of surprising rules and we do use RM references
there.

As I pointed out in my example, gratuitous RM references,
where you take a simple thing like an undefined variable,
and add a completely unhelpful RM reference to some of the
most complex sections of the RM (the ones on visibility),
are simply annoying. Once again in this example:

   "QXR" is undefined

If anyone cannot understand this message, then there is no
way that an RM reference is going to enlightent them.

The useful constructive thing here is to note *specific*
cases of unclear error messages, where additional
explanation or additional warnings are required.

Let me take an example:

  procedure z is
    type r is access integer;
    a : aliased integer;
    b : r := a'access;
  begin
    null;
  end;

This program is obviously incorrect, and indeed I would
expect anyone who is at the level of reading the RM to be
able to immediately figure out the error on line 4, even if
the compiler just said "ERROR" and nothing more.

For the less initiated user, this can be a confusing
situation. We used to simply say:

     4.   b : r := a'access;
                    |
        >>> result must be general access type

But we found many people were confused. For one thing, the
terminology "general access type", completely familiar of
course to anyone who knows the RM, is likely to be
confusing to neophyte users.

Now how to fix things? Add an RM reference? I cannot
imagine that sending someone who does not understand the
above message to the RM could possibly help, and on the
contrary, it would tend to just increase the confusion
level. The RM is NOT the place to learn Ada!

So what did we do in this case, we added an extra message:

     4.   b : r := a'access;
                    |
        >>> result must be general access type
        >>> add "all" to type "r" defined at line 2

and since then, we have got no further confusion queries
on this particular message.

In some other cases, we do find an RM reference helpful,
here is an example:

  1. with System; use System;
  2. procedure z is
  3.   g : Address;
  4.
  5.   type x is record
  6.      m : Integer := 3;
  7.   end record;
  8.
  9.   y : x;
 10.   for y'address use g;
                         |
     >>> invalid address clause for initialized object "y"
     >>> reference to variable "g" not allowed
         (RM 13.1(22))

 11. begin
 12.    null;
 13. end;

The RM reference here is useful to point out a change from
Ada 83 to Ada 95, and a rather obscure rule limiting what
address clauses must be accepted.

I am certainly not saying that all the error messages in
GNAT are perfect, far from it, and we are always putting
in a lot of effort to improve them. But the above should
illustrate the philosophy behind their formulation.

What is useful is not a general recommendation to put in
RM references, most of which would indeed be gratuitous,
but rather comments (preferably sent to report@gnat.com)
about specific messages where you have suggestions for
improvements. If you think an RM reference would be
helpful, then suggest the specific RM reference that you
think would be helpful).

Robert Dewar
Ada Core Technologies

P.S. The point above that people should suggest specific
RM references that they think would be helpful is one I
have made in this and other forum's often before. It is
interesting to note that although we have received hundreds
of suggestions for improving error messages, only *one* of
these suggestions included a specific RM reference (and
indeed it was a helpful suggestion which we followed).



-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own