Re: What is wrong here? (Generic and controlled types)

[Robert Dewar <robert_dewar@my-deja.com>]

In article <38EC6B3E.9225F1D4@mail.com>,
  Mats Weber <matsw@mail.com> wrote:

> I think the message is misleading (both the actual GNAT
message and the
> above modified version) in the sense that it does not direct
the user to
> the actual rule he is violating, which is that one cannot
derive a
> tagged type at a level deeper than its parent.

Now there (to me) speaks the expert who knows far too much.
An error message that said

"tagged type cannot be derived at a level deeper than its
parent"

would be truly useless to almost all users. Most people don't
even think of controlled types as tagged, and almost no one
understands the concept of "level deeper".

Yes, to the expert, many GNAT error messages are not 100%
technically correct. This is by design. The issue is whether
the message would mislead an expert, and the answer is of
course no, because they understand the underlying reason.

Many compilers to me generate far too much technical term
gobbledygook. Indeed note that the objection that has arisen
to this message is the (to me unanticipated) objection that
library level is an obscure technical term.

I consider this objection valid, and we will think about how
to avoid this mistake.

There may be an argument for making the RM technically precise
and thus much less accessible (even there as you know I am a bit
dubious), but arguing to make error messages more
technically precise at the expense of accessibility would be
a huge mistake I think.

It is interesting to argue about whether an RM reference would
help. The RM reference would indeed be to the section in the
RM talking about rules for deriving tagged types in terms of
accessibility levels.

For putting the RM reference in:

  This helps to explain to an experienced and knolwedgable
  Ada programmer *where* the restriction comes from in the
  language design, but does not help fix the problem.

Against putting the RM reference in:

  There are two kinds of programmers. Some will understand
  the message without the RM reference, and go fix things,
  without bothering to look at the RM. They don't need the
  RM reference!

  The second kind can't understand what the message means
  (note that we had some pretty skilled programmers responding
  in this thread that they were in this class). They will go
  looking up the RM reference hoping it will help them
  understand. The trouble is that this particular RM reference
  is very unlikely to be enlightening (remember we are talking
  about programmers who don't know what library level means).

To me the balance of this argument says don't put in RM
references. I notice that whenever we argue about the RM
reference issue, it is almost always pretty expert programmers
who want those references :-)

But whereever that argument leads, to me the major task is to
improve the quality of the error messages so that *in practice*
more programmers fall into class one.

Robert Dewar



Sent via Deja.com http://www.deja.com/
Before you buy.