Re: Required Metrics

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

In article <mUfR4.8835$wb7.709941@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:

> IF IT'S A REQUIREMENT, IT SHOULD BE TREATED AS SUCH. THAT IS,
> IT SHOULD CAUSE THE IMPLEMENTOR TO DO SOMETHING.

Sounds reasonable to me! No one ever argued any differently.
In fact most people would go further and say that if something
is not testable, then it's not a requirement.

> IF IT'S NOT A REQUIREMENT, IT SHOULD NOT BE IDENTIFIED AS
> SUCH.

I think you mean "if it's not a requirement in the above
sense". Obviously requirements are precisely things that are
identified as requirements, so the above sentence stated as
you gave it is tautologically true.

> USERS (AND VENDORS) SHOULD BE CONFIDENT THEY KNOW WHICH PARTS
> OF THE STANDARD ARE IDENTIFIED AS REQUIREMENTS, BUT DO NOT
> CONSTRAIN BEHAVIOR.

Well I'm pretty confident, since it's pretty clear, sorry that
it continues to be unclear for you!

> Clearly, what you don't understand is that a requirement that
> is always met by definition, is not a requirement.

So Ken Garlington pronounces, but can Ken Garlington prove this
statement from the RM. I think not. Again, the "is not" here
is confusing, I think you mean "should not be".

It is quite clear in the RM what is and what is not a
requirement, from the headings. The fact that the definition
of requirement does not meet your definition is pretty much
irrelevant from the point of view of analyzing the existing
RM.

You could get lots of people to agree with a statement that
all requirements in the reference manual should be testable,
at least conceptually.


> REQUIREMENTS SHOULD CONSTRAIN BEHAVIOR. IF THEY DON'T, IT'S
> WRONG TO CALL THEM REQUIREMENTS.

Ah now that of course is a much better form, because now you
are giving Ken Garlington's opinion. Do I agree? Well I don't
understand "behavior" in a mathematical sense, it sounds more
like a software engineering sense. If the above statement is
equivalent to:

REQUIREMENTS SHOULD BE TESTABLE. IF THEY ARE NOT, IT'S WRONG
TO CALL THEM REQUIREMENTS.

Fits better into a language standard, and that of course I
agree with. Remember that Bob Duff and I both strongly objected
to all these ill-defined "requirements" in the reference manual.
Informally I agree with your statement, it is just not stated
in a well defined manner, because it uses terms "constrain" and
"behavior" that cannot be given formal semantic meaning.

Remember we are ALWAYS in the realm of the formal semantic
definition, so pronouncements about what this formal semantic
definition should or should not contain should try to avoid
making the mistake of themselves not being formally stated.

The standard is NOT about constraining implementors, in fact
the standard has nothing to do with implementors at all. It
is simply a definition of what it means to conform to the
ISO standard.

If someone constrains an implementor to conform to the standard,
then the language of the standard will be relevant. But it is
the someone, not the requirements, that are doing the
constraining.

That's an important difference, because for example, the ACVC
test suite IS all about constraining implementors and has quite
a different viewpoint than the standard itself.


> If that's the case, then all you have to do is identify
> which "requirements" fall into this category.

Nope, I don't *have* to do anything of the kind, it does not
seem important to me to do so at this stage for several
reasons:

1) I don't think any real users are affected by this one way
or another. Theoretical conversations on CLA don't have very
much to do with real users.

2) We went through the excercise during the design process, and
surprisingly lots of people wanted to keep in these ill-defined
"requirements". There is no reason to think that anything has
changed. The fact that Ken Garlington may or many not understand
things differently is irrelevant. Certainly Robert Dewar's
understanding has not been changed one iota by this exchange.
He still thinks that documentation requirements etc should never
have been included in the standard as normative, and nothing
that has been said here has changed his mind, but he never
makes the mistake of rearguing old points unless there is new
data!

3) The ARG has many more important things to do than sit around
in angels-on-a-pin-head discussions that have no actual effect
either on compiler writers or compiler users.

> Isn't this why you have a standards process? Users bring ideas
> to the table; they're discussed by other users, implementors,
> and other interested parties, and if THERE'S A CONSENSUS they
> get implemented?

Only for well defined semantic features. This discussion is
all about things not meeting that requirement. Go look up your
previous post where you mention sharing costs, you were not
talking about static pointers, but about metrics!

> "if you're going to implement this sort of
> feature, we'd like to have some level of standardization as to
> what it means. Is this possible?"

Just as I thought you were beginning to understand :-(

Now, not only are you defending requirements like the
documentation requirements for pragma Reviewable, you are
suggesting that this information be output in a standardized
manner -- worse and worse if you ask me! Do you want to
specify the font used :-)

> Fine. So which parts of the standard are this "formal
> English," and which
> aren't?

The entire normative part of the standard should be read
as formal english. I am surprised anyone would ask this
question. It just goes to show the danger of making standards
accessible :-)

Don't get me wrong, I think it is great for the standard to be
accessible, and I am one person who liked the less formal style
of the Ada 83 standard better than the more formal language of
the Ada 95 standard, but it does have this risk of people
reading things and interpreting them informally.

> For example, the following implementation requirement seems to
> dictate
> certain input-output properties that a compiler must have:

> "The implementation shall provide control- and data-flow
> information, both within each compilation unit and across the
> compilation units of the
> partition."

It might, except the phrase "control-flow information" is
undefined, and even as an expert compiler writer, I can only
guess what it might mean.

Actually I don't think it dictates any input-output properties,
since the RM makes clear that documentation on implementation
dependent features (most certainly this information is in that
category) can be provided by simply pointing to HOW to find out
the information. I assume this means that "control flow
information" can be determined by following a debugger, now
that's REAL useful.

Perhaps the writers of this paragraph had something specific
in mind, but they sure did not express it. I suspect if they
HAD tried to be more specific, no one would have put up with
it even in annex H (which is worse than other sections of the
RM in many respects when it comes to being formal and precise).

> I know it's not testable through an ACVC-style test, and that
people can
> differ on the meaning of the definition, and that this
requirement
> "distorts" the standard. I just don't see how it answers the
question.
> Please don't spend too much time explaining all of this to me
again. It's a
> simple "yes" or "no" question.

No it isn't, I can't find any simple yes or no question in
what you wrote.


> You've made it fully clear that a language standard does not
> exist to address user needs.

And that's a bit of a pathetic, but VERY revealing statement.
The language standard exists for one purpose and one purpose
only, to define exactly what it means for a compiler to conform
to the ISO standard.

Ken Garlington may not find that this narrow objective addresses
his "user needs", but I can *assure* you that the great majority
of our users find the existence of the standard and the
associated conformance testing vital, and it most certainly
addresses their needs.

Now of course they do NOT make Ken's mistake of thinking that
the standard can do any more than that, and that my some magic
rewording of the standard, he will no longer have to write
special requirements for his compilers, and will be able to
avoid spending unreasonable amounts of money getting the tools
they need.

It's been useful to have someone like Ken put into very clear
perspective the frustration that he and others feel that the
standard cannot guarantee them high level compilers, and you
can see from his posts how reluctant he is to abandon this
goal. Moreover, as he begins to see that this guarantee might
not be possible, he rushes to the conclusion that the standard
does "exist to meet user's needs".

This viewpoint of the standard as a complete requirements
document is an amazingly common one. But it was never and
will never be a useful one. We probably even still have
people around who hold the closely related fantasy that
validation testing of compilers will assure quality. This
is a closely related issue, and the natural consequence
of Ken's view of the standard is presumably that ACVC
testing does not "exist to meet user's needs", since it
shows partial conformance to the standard, nothing less
and nothing more.


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