Re: Getting GNAT to issue ARM error messages

[dewar@gnat.com]

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