Re: Required Metrics

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

In article <uegR4.8838$wb7.710909@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> Apparently, we're going to have to agree to disagree as to
> whether it's a problem if the vendor decides a requirement
> doesn't constrain his behavior
> (and doesn't even have to tell anyone which requirements he
> decided fell
> into this category).

Ken, always remember that I was one of the ones who think
it was a huge mistake to include ill-defined requirements
in the RM. I think it's definitely a problem, if for no
other reason than it leads you and others to be confused.

That's why I think it would have been FAR better to have
all such "requirements" be implementation advice instead
for the following reasons:

1. We can say far more information things under the IA
than in the requirements section. The non-normative
sections of the RM, including all IA, are not in formal
english, and can be read informally, which is far more
useful in this case.

2. We would word them with this in mind, so that they
would be clearer when interpreted this way.

3. Implementors would indeed have to say whether they
meet the IA in each case or not (OK, to T.E.D, yes this
is not a formal requirement, but in practice it is well
understood, and customarily followed, at least I assume
all decent Ada 95 compilers provide this useful information).

If it is important to you to have implementors tell you how
they deal with each such "requirement", you can only get
that if they are IA. For real requirements, you either meet
it or you don't, and there is not a hint of an obligation
to say *how* you met the requirement. For example, I don't
have to tell you how I compute the sqrt function. There is
no such requirement for information provision, even in an
informal woolly sense.

One would have thought that the people who demanded that
documentation be included in the RM would have also pushed
for requiring documentation documenting that documentation :-)

But they did not, or very properly, such a suggestion was
rejected in the context of formal requirements.

Ken, is this really all new to you? It is really a very familiar
issue to those involved in the language design. I am a bit
surprised by all this sturm and drang over an issue that was
laid to rest 5 years ago, after extensive discussion.





> Why does someone have to "make sure" they have to meet a
> requirement that they've decided does not constrain them in
> any way?

Sorry, I don't understand. Each requirement is addressed from
the point of view of whether the compiler meets it, not whether
it "constrains" you, whatever that means.

> Do people who don't
> drive cars spend much time worrying if they're driving over
> the speed limit?

This is not relevant at all, nice rhetoric, but completely
irrelevant.

A compiler vendor must look through the documentation
requirements, and make sure that they are satisfied according
to the vendors best reading of the reference manual. If the
vendor is relying on 1.1.3(19), they need to think about whether
this applies. It may take little thought, but little is not
zero.

> Now we're getting to the question that wen't unanswered
> before. How do you do this? Is there a checklist? What
> criteria do you use to determine if you've met all of the
> requirements that aren't part of the "formal
> semantics"?

This is simply not a hard job to do for people who understand
what the standard is about, and who know and understand the
standard well. Remember the DOC does NOT say you meet all
requirements (such a DOC would be unsignable, since as I
mentioned before, it would be a declaration that you had
no bugs). The DOC declares that you have no intentional
deviations from the standard. So the process of signing the
DOC is precisely to make sure that you have no intentional
deviations.

> If there are requirements that the vendor decides are
vacuously true, is
> there any "moral" responsibility to either (a) verify this is
the case,
> and/or (b) document the decision?

For requirements that are ill-specified and untestable, it is
clearly impossible to formally verify that the requirement has
been met. You simply do the best you can in such cases to make
sure that the requirement is met. There is no hard and fast
division into requirements that are or are not vacuously true.
You have seized on this phrase, but it is not useful to do so.

I have no idea what morality has to do with a formal language
definition. Most certainly there is no requirement at all
to document decisions, because no decisions have been made.
You paint a picture in which the vendor lines up all the
requirements, and then "decides" which are vacuously true
and can be ignored.

I know of know vendor who goes through such a process. Rather
you go through all the requirements, and as best you can, make
sure you have met them. That's all, nothing more, nothing less,
and you do NOT have to document the fact that you conform to
each individual decision, or how you conform to it.





> Oh, we always got what we wanted -- just before the vendor
> went out of business.

Well I guess you were not very good at picking vendors then.
Too bad, but it's not something the standard can help you with.

> We're just tired of having to go through the cycle over, and
> over, and over again.

Lots of Ada users do NOT have the experience of going over a
cycle of vendors going out of business over and over again, so
this is definitely avoidable. Perhaps you need to look to your
procurement procedures, they sound shaky, at least if judged
by results. In any case the standard is not going to be able
to prevent this I am afraid.

> You're quite correct that we have to shoulder our part of the
> blame. We thought that Ada would naturally win out in the
> marketplace, because it had all of these advantages over other
> languages, and so we were an early
> adopter.

Well many early adopters of Ada have had very good experience.
Maybe they know something you don't, or they have better
procurement procedures. I don't think you can blame all your
difficulties on early adoption.

>  Now, we know better. Rather than trying to drive the
> marketplace, we adapt our requirements to what's out there,
> and to what vendors are
> willing to implement on their own dime.

Well more accurately, what they are willing to implement to
meet general requirements of the Ada community. That's a little
different. Certainly all of ACT's development is paid for by our
paying users. We have no outside investment, so we have no
"our own dime". All the dimes come from customers, so we try
to spend them wisely in a way that corresponds to the general
needs that they have.

> Custom requirements are a sucker's game.

They certainly can be, and it sounds like you have been sucked
in, but that's largely your fault. Your new approach of looking
to see what's generally available, rather than demanding the
implementation of custom tools sounds like a FAR better way to
go. Of course it's not absolute. As I said before, we do many
small enhancements for our customers as part of our regular
support. We also implement special features on a contract basis
when there are special needs, but we will only do this if we
think the features are generally useful.

I definitely agree that the Ada 83 world was too full of
custom requirements. Isn't this a general problem in the
past history of the DoD? Aren't million dollar Ada compiler
tool sets pretty closely related to $500 toilet seats? :-)

Robert Dewar
Ada Core Technologies


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