Re: Required Metrics

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

"Robert Dewar" <robert_dewar@my-deja.com> wrote in message
news:8f49je$pti$1@nnrp1.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.

Excellent! So, when you were implementing the requirement described in H.3.1
that says, "The implementation shall provide control- and data-flow
information, both within each compilation unit and across the compilation
units of the partition," what was the something you did in the
implementation to meet that requirement?

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

No, but I can "prove" this by referring to the nearest dictionary:
"requirement. something essential to the existence or occurrence of
something else." If there are statements in the RM that are not essential to
the existence of anything in the implementation, why would they be
considered requirements?

Perhaps the language specification does not use terms in either the software
engineering or English language sense?

I can, of course, also indirectly infer the meaning of requirement from
1.1.2:37.

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

No more than "if an apple is identified as a banana, it's a banana ."

Apparently, however, this does not translate to language specifications. If
I understand you correctly, I could replace the word "requirement" with
"fodasugfdu" with no ill effects, or (more importantly) replace "advice"
with "requirement".

> > 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!

Can you then translate that confidence into words more precise than "formal
semantics" (which, as we've learned, is not related to the terminology used
in the ARM), or "a specification of input-output relationships" (for which
counter-examples exist; e.g. pragma Reviewable), so that we know which parts
of the RM are essential to the existence or occurence of something else?

> Nope, I don't *have* to do anything of the kind, it does not
> seem important to me to do so

OK, then why are you responding to this thread? Simply say, "Sorry -- your
problem is just not interesting enough to work" and be done with it?

It seems important to me to do so, because:

> I think it's definitely a problem, if for no other reason than it leads
you and others to be confused.

Given that, it is strange to conclude that:

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

Just as it is quite clear from the headings what is and is not formal
semantics, I presume?

Just as you continue to refer to implementation requirements as
documentation requirements, as in:

> Now, not only are you defending requirements like the
> documentation requirements for pragma Reviewable,

And yet, somehow the phrase "well defined" continues to appear, as in

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

Where each vendor not only gets to define those features, but in fact may
not be able to articulate which specific parts of the standard are in that
category? That doesn't seem very "well defined".

> Go look up your
> previous post where you mention sharing costs, you were not
> talking about static pointers, but about metrics!

Actually, I was talking about the "implementation requirements" of pragma
Reviewable -- the idea being that if users in a "special needs" area (like,
say Safety and Security) commonly needed some output from the compiler
(e.g., those commonly required by DO-178B), that it made sense to identify
that output in a standard, to the level of detail that the implementors
could stand (which, of course, would not include the report content or font,
or even if it were generated as a standard "report" at all).

I don't think I provided one word of input regarding metrics during the
standarization process.

However, now that I've learned that:

> The standard is NOT about constraining implementors, in fact
> the standard has nothing to do with implementors at all.

then I guess it doesn't make any sense to talk about the standard with
implementors!

[the usual strawmen of testing, the extent to which the standard addresses
all the users needs, etc. ignored]