Re: Getting GNAT to issue ARM error messages

[robert_dewar@my-dejanews.com]

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