Re: Required Metrics

[Robert A Duff <bobduff@world.std.com>]

I think the answer to your original question is, "Yes, the Metrics are
real requirements, but it's not clear exactly what they mean."  In other
words, it's a matter of judgement whether or not a given piece of text
constitutes proper documentation.  I would have to agree that a
statement like, "Documentation not yet available" is a clear violation
-- I can say that without defining precisely what the rule means.

I strongly agree with Robert Dewar's statement that Documentation
Requirements should not be in the standard, and I said so many times
during the Ada 9X design.  Many people, including Tucker, did not agree.

And I think the Metrics are the worst sort of Documentation
Requirements.

Putting Doc Requirements in a standard shows confusion as to what
standards are for.  Standards are not about forcing or encouraging
people to make high quality implementations.  Standards are about
encouraging uniformity.  IMHO, of course.  ;-)

Furthermore, Doc Requirements distract implementors from the real goal,
which is good documentation.  Look at any vendors Doc Requirements
documentation.  You will usually see a long list of poorly organized
snippets of confusing, out-of-context, information.

> I get a queasy feeling when it seems that the Ada vendor community may not
> be addressing requirements they don't like. First, it doesn't seem to be a
> very "software engineering" oriented solution, given how Ada folks are
> supposedly more "software engineering" oriented than users of other
> languages. Second, how can anyone claim that an advantage of Ada is
> standardization, if vendors don't have to follow parts of the standard that
> are hard to implement, or that they just don't like?

You have a point.  However, in this particular case, if vendors fail to
provide the required documentation, that has absolutely zero effect on
portability.  The advantage of having a standard is portability.  So
it's hard to get too excited about a rule in the standard that has no
effect on portability.

> I'd hope we all agree that a compiler that passes the validation suite, but
> can't handle *any* other valid Ada program, is also in practice not useful
> for users, and should be universally denounced as not compliant to the
> standard.

Sure.

>... However, once we start down the path of ignoring the requirements
> we don't like, we lose any right to complain about such a case.

That would be a stronger argument if we were talking about some language
feature.  Eg, we all know Robert Dewar hates asynchronous transfer of
control, but it would be annoying indeed if GNAT didn't implement it.
Likewise, I hate modular types -- but of course I don't refuse to
implement them in the AverStar compilers, and I don't insist on changing
the rules to be more to my liking.  These would be true even if the
ACATS didn't test for these features.

> It seems to me in the Ada83 days that AIs were used to develop and document
> consensus on clarifications, etc. to the standard. Is this no longer used?

The ARG still exists, and still generates AI's.

I suspect that if you sent in a question saying "Are the metrics really
required?", the ARG would issue a ruling saying, "Yes, of course, it
says so in plain English."  (I'm not sure of that; some people might use
it as an opportunity to get rid of these silly rules.  Some people might
take the attitude that you can't require something unless you can
precisely define it -- and thus declare the metrics to be meaningless
gibberish.)

On the other hand, if you asked, "What, exactly, do the metrics
require?", the ARG would refuse to waste time trying to answer the
impossible.

So, whatever compiler it was that said "Documentation not yet
available", send them a bug report.  I wouldn't be surprised if it's our
compiler.  ;-)

- Bob