Re: Required Metrics

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

In article <3914F1DC.A5EE1751@earthlink.net>,
  "Robert I. Eachus" <rieachus@earthlink.net> wrote:

>    On the other hand, everyone involved in the process was
aware of what
> had happened in Ada 83 with most of Chapter 13.  Some vendors
ignored
> the parts that weren't tested, and other vendors since the
requirements
> there were not tested put implementation of those features at
low
> priority.  (If a customer came alone with a need and
sufficient cash,
> they move up the list.  But the users were not particularly
happy with
> that either.)

As one very much involved in this issue (I campaigned for
the chapter 13 tests to be included in the ACVC suite, and
consulted extensively with the AVO making that happen - quite
a bit of the code in those tests is mine :-) let me comment.

It's not so simple. These were not clear requirements that
were being ignored. The precise trouble was the infamous
"simply" clause. Here it is:

  An implementation may limit its acceptance of representation
  clauses to those that can be handled simply by the underlying
  hardware.

And the word "simply" is nowhere defined. Well this is the
proverbial hole big enough to drive a truck through.

Robert Dewar (and others) argued that simply must be interpreted
in solely technical terms, looking at sequences of machine
instructions. Even this leaves some subjective margin (is 3
instructions simple? 10? 20?).

But others considered that simple means simple to implement
and used this as an escape hatch to pick and choose what to
implement.

Not till the ARG ruled clearly on this issue, and the AVO
backed it up with the tests (which as I mention above, I
helped write), in ACVC version 1.10, did a proper set of
tests get written.

Now in Ada 95, we did two things

  1. Required (in the systems programming annex) that rep
  clauses be implemented.

  2. Specified an exact set of rep clauses that must be
  implemented.

Was this an improvement?

Yes, and No. Yes, if you agreed that the old Ada 83 requirement
was so ill-defined as to say nothing, since now we clearly DO
have a set of required rep clauses. Of course we achieved this
in Ada 83 too by ARG rulings and the introduction of ACVC 1.10.

No, if you take Robert Dewar's fierce interpretation of the
original Ada 83 rule. Right now, there are lots of rep clauses
that can be implemented simply in the hardware, which are in
my opinion required by the Ada 83 standard, but which FOR SURE
are not required by the Ada 95 standard.

Overall are we ahead? Well in practice I find the subset of
rep clauses required by the Ada 95 RM pathetically inadequate.
In particular, an Ada 95 compiler that implements ONLY this
minimal subset will have a really painful time with legacy Ada
83 compilers, which in general implemented a FAR larger set of
representation clauses.

Certainly in GNAT we go way beyond the Ada 95 requirements,
and we attempt to completely match the capabilities of the
Ada 83 compilers and in some cases, we go significantly beyond
those requirements as well.

Why? Because the standard is not the driving force when it
comes to rep clauses, yes, of course we meet the limited
requirements of the RM, but the driving force here is customers
and Ada 83 legacy code.



> For example, how do you design a portable
> test for the bit patterns used to represent enumeration types?

<<discussion of why this is hard snipped>>

Yes, it's tricky, but can be done. This is one particular
problem that I provided the solution for, and my solution
(involving carefully chosen use of unchecked conversion is
in the ACVC suite since 1.10). I think you can find my name
on that test still :-)

> This is why many of the documentation requirements are
> untestable.  For example, the intent of D.8(10) is clear:

> If the documentation says the upper limit is one million
> clocks is it useful?  Probably not.

Ah thanks Robert, I had forgotten that very useful point. Yes
indeed, another completely accurate way of meeting the metrics
requirements is to provide silly bogus figures like this. In a
software engineering document, you can avoid this problem, most
likely by specifying actual absolute performance criterion for
the particular hardware combination you are using, but an
attempt to plug this hole in the RM would lead to even more
murky situations.

> The compromise, if it can be called that,
> is found in RM 1.1.3(19):
>
>   "The implementation may choose to document
>    implementation-defined behavior either by documenting what
>    happens in general, or by providin some mechanism for the
>    user to determine what happens in a particular case."

Interesting -- I had COMPLETELY forgotten this
statement in the standard. It is of course an exact codification
of some of the things that Bob Duff and I have argued. In
particular, it provides an absolutely CLEAR basis for Bob Duff's
observation that the behavior of the delivered binary compiler
code, and the behavior of code generated by this compiler
constitute documentation in the sense of the RM.

So the RM *did* try to define what documentation meant, and
came up with something about as far from what Ken has in mind
as one can imagine.

All the more reason to accept my point that we would have been
far ahead putting documentation requirements in IA sections,
where the word documentation can appear without being defined
in a more useful subjective form.



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