Re: Required Metrics

["Ken Garlington" <Ken.Garlington@computer.org>]

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8f3s87$bsc$1@nnrp1.deja.com...
> In article <Gt7R4.8719$wb7.695096@news.flash.net>,
>   "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> > > (by the way, I suddenly realize that you Ken
> > > converts my general use of semantic into the headings in the
> > > manual, don't make that mistake, semantics includes a lot
> more
> > > :-)
> >
> > Excellent! Light begins to dawn. Now, the slippery part: How
> > much more?

This, of course, is a key question, which went unanswered in the last
response. I thought I'd put it up here, so it wouldn't be missed.

> But the trouble is that if a requirement has no formal content,
> then in the context of a language standard, it can be met in
> almost anyway.

The word "almost" is the one that interests me. All we have to do now is
decide if it really belongs in that sentence, and we're home free. Earlier,
you appeared to be saying that certain items in the standard, labelled as
requirements, did not constrain implementor's behavior -- they were
vacuously met. Now, you appear to be saying, through the use of the word
"almost", that it is possible for an implementor to fail to meet a
requirement with "no formal content."

Again, to review, there are three questions I care about:

1. Under what conditions could a vendor fail to meet the metrics
requirements, the documentation requirements, and other requirements of this
type?
2. If there are no such conditions -- they do not constrain the
implementation in any way -- is it appropriate to call them requirements?
3. Is there a consensus as to which "requirements" are always met by
definition?

Note that discussions of what the language standard _should_ contain, or how
it should be tested, or whether users should express their needs in language
revision meetings (?!?) are interesting, but off-topic. For example:

--- OFF-TOPIC CONVERSATIONS FOLLOW ---

> > No, I mean that you may believe that the ACVC review board
> > agrees with you, based on your statement in a previous post:
> >
> > "By the way, the ACVC review board discussed this briefly.
> They immediately
> > agreed that these requirements were too ill-defined to even
> consider
> > including them in conformance assessment."
>
> Right, this was a completely uncontroversial position. I cannot
> imagine anyone who understood the notion of language
> definitions, conformance and validation testing disagreeing.
>
> What would you have in mind? That we have a section of the ACVC
> testing that includes Ken Garlington sitting down, reading the
> documentation and announcing that it meets his (nowhere defined)
> criteria for acceptable documentation? Ken is free (more than
> free, encouraged) to do this as part of his acceptance testing,
> but only for his own purposes.

Nope, I have in mind what I've said all along. If there are requirements in
the standard, then they should in some way constrain the behavior of those
implementing them. How they constrain the behavior is a different subject.
I'm perfectly comfortable with the statement that some requirements are
vague, can't be qualified by testing, etc. Have been from the beginning of
the post. For example, I noticed you failed to respond to my answer to your
question, "what happens if the vendor decides to write his documentation in
Klingon?". That same answer applies here.

I know you feel more comfortable bringing up this ACVC strawman, or this
"user preference" strawman, as you have done it several times. It has no
bearing on my point, which I made in an earlier part of the thread, and will
repeat now:

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

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

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

Clearly, what you don't understand is that a requirement that is always met
by definition, is not a requirement. It doesn't constrain behavior, so it's
not a requirement. I know you're reading these really fast, and trying very
hard to pull out some underlying meaning having to do with testing, etc.,
but you need to stop. You're just confusing yourself. For a moment, just a
moment, assume there's no underlying agenda. Just read these words, slowly:

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

If you disagree, let me know. From what you've posted elsewhere, it appears
that you agree. If that's the case, then all you have to do is identify
which "requirements" fall into this category.

> Actually Ken, you said something VERY revealing earlier on. You
> talked about tightening up the standard to make compiler vendors
> do stuff that they had not done in Ada 83 compilers in this
> area so that the costs could be shared.
>
> Let's examine this thought a bit further.
>
> First. It's really an inappropriate distortion of the market
> to attempt to include requirements that YOU want, but the
> market place does not in general want, in an attempt to get
> other people to pay for things that you need that they don't
> want (if they wanted them generally, they would be there,
> competition works that way).

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?

I brought a requirement to an SEI meeting with Goodenough and co. during the
language revision process for "static pointers." We were having to do a lot
of non-portable things like Unchecked_Conversion in Ada83 to achieve this.
The 95 standard has new features that address this need. Did I "distort the
market" by doing this? If so, why did you guys ask me for inputs?

Seems to me the argument "competition works that way" could imply that
there's no real reason to have an ISO standard. It seems to be working
reasonably well with Java; I haven't had any problems porting between MS
Visual J++ and Sun Java, for example.

With respect to whether others in the market place want the requirements of
pragma Reviewable; at least for the ones I wanted, Aonix seems to think
there's a market, and I didn't even have to pay them! Too bad we couldn't
get the vendors together and say, "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?"

> Second, Even ignoring the dubious justification for such an
> attempt, it is bound to fail. Why? Because language standards
> are not about providing good documentation, useful information,
> or even about producing usable compilers. They are nothing more
> than a set of mathematical formulae, informally expressed in
> this case, that dictate certain input-output properties that
> a compiler must have. The language standard by its nature can
> only ever be a small part of the requirements.

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

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."

Input -> source code defining compilation units of the partition.
Output -> Control-flow and data-flow information.

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.

> You might hope that "beefing up" the standard would help solve
> YOUR problem and relieve you of YOUR responsibility for devising
> the set of requirements for your tools and making sure you
> acquire tools that meet these requirements, but this attempt is
> bound to fail.

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