From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,66752102482bbdca X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: Required Metrics Date: 2000/05/07 Message-ID: <8f3s87$bsc$1@nnrp1.deja.com> X-Deja-AN: 620266451 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> <8es5fv$4ov$1@nnrp1.deja.com> <_HnQ4.7884$wb7.550012@news.flash.net> <8eukm0$ssm$1@nnrp1.deja.com> <8f26s6$lrj$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x27.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Sun May 07 13:48:58 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-05-07T00:00:00+00:00 List-Id: In article , "Ken Garlington" wrote: > > Nope! No "song in the heart", which I take to mean with an > > intent other than a formal declaration. Perhaps you have > > some other meaning, if so, it is obscure to me. > I do have some other meaning, and apparently it is obscure to > you (even though you quote its meaning in the following): OK, you still don't say what that "other meaning" is. > or vacuously met, to quote previous posts? as in: "all other > requirements are 'met' no matter what"? > > Perhaps you have some meaning for vacuous or trivial that is > obscure to me! Right, as I said earlier, I think the problem you have in understanding just comes from unfamiliarity with the notion of formal language definition, and the history and function of language standards documents. You are expecting them to do something they can NOT by nature do, a common misunderstanding indeed. As I say, closely related to the peculiar notion, so very common in Ada 83 days, that validation guaranteed quality and usability. > 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. 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). 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. 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. Language standards are NOT software engineering requirements documents, and no amount of yelling or complaining can change this fundamental fact. > > Isn't it at least possible that I simply mean what I say? > > > There is no list of non-requirements, because there are no > > non-requirements. THe DOC requires that you have not made > > any intentional deviations from the FULL SET of requirements, > > including the documentation requirements. > > > > > You might want to re-read your original statement: "How can > > the DOC be > > > signed if you have ignored a requirement?" Note that the word > > > "intentionally" does not appear. > > > > intentionally is of course critical. Otherwise the DOC would > > be a declaration that your compiler was bug free. This is not > > intended, and would be impractical. > > That's right. You can sign the DOC "with a pen in the hand and a song in the > heart", and still make an unintentional mistake. Perhaps, even, a certain > kind of unintentional mistake relevant to the topic at hand. And yet, the > meaning of my statement above still eludes you. Unfortunate, but there's no > point in banging my head against that wall any further. > > > > > Nope, the issues with pragma Reviewable are also all > > > > documentation based, let's look: > > > > > > Yes, let's. Specifically, let's look at the words which appear > > just before > > > paragraph 5: > > > > > > ***** Implementation Requirements ***** > > > > > > "5 The implementation shall provide the following information > > ..." > > > > > > Now, I suspect you're using the term "documentation" > > informally, not in the > > > sense of ARM 1.1.2. However, since all Implementation > > Requirements, like all > > > Documentation Requirements, are not really requirements, > > perhaps we _should_ > > > use the same name for both. > > > > Of course implementation requirements are requirements, what > > gave you the lunatic idea that this is not the case. I say > > lunatic here, because it simply makes no sense. There are many > > critical implentation requirements. Where ON EARTH did you > > get this idea, certainly not from anything I wrote. > > Except for the bit you quoted from your earlier post: > > "Nope, the issues with pragma Reviewable are also all documentation based, > let's look:" > > So, which is it? > > (a) the ***implementation*** requirements for pragram Reviewable should be > treated like documentation requirements (vacuously met), or > (b) they shouldn't (i.e. it is possible to fail to meet them). > > If (a), then how does someone determine which other ***implementation*** > requirements are vacuously met, and which are critical? > > > This is formally definable, and of course tested by the ACVC > > tests. Again, I ask where did you get the idea that > > implementation requirements are not requirements??????? > > From you. You should really read the implementation requirements for pragma > Reviewable, they're quite extensive. None are tested by the ACVC, of > course... > > > > > > When we were discussing these safety and security requirements > > during that > > > industry-implementors meeting lo these many years ago, I was > > frankly > > > surprised that the vendor representatives (including yourself) > > didn't put up > > > more of a fuss. Now I see why. What a total waste of our time. > > > > Actually many useful things came out of those meetings, but if > > you thought that the meetings were about requiring vendors to > > provide useful usable implementations, you were indeed deluding > > yourself, since language standards can never guarantee this. > > Actually, I thought we were working on a useful usable standard. That is, an > agreement from the vendors as to the text of the implementation requirements > included the concept that the vendors understood what they meant! > Apparently, I was mistaken. > > > > !topic Non-Requirement Requirements > > > !reference RM95-1.1.2(24-39) > > > !from Ken Garlington 00-05-05 > > > !keywords requirements, advise > > > !discussion > > > > > > The referenced paragraphs define several different categories > > of the > > > standard. Some of these categories use the term > > "requirements," although > > > they are not considered requirements by the Ada vendor > > community. There > > > should be an explicit list of which categories can be > > considered > > > requirements (i.e., it is possible for a vendor to "fail" to > > meet it). All > > > other categories should be described in the terms currently > > used for > > > "Implementation Advice." > > > > > > This is plain silly, I can't imagine the ARG giving it much > > attention, since it amounts to nothing more than an unfounded > > polemic. There is no part of the Ada community that considers > > any requirements in the RM not to be requirements, and > > certainly the vendor community does not ignore any requirements. > > Note my definition of a requirement: "i.e., it is possible for a vendor to > 'fail' to meet it." So, which is it? > > (a) There are areas of the standard that have the word "requirement" > attached to them which are vacuously met by all vendors. > (b) There aren't. > > You may consider it "plain silly" to take items in (a) and label them > implementation advice, and I'm sure the ARG will give it no attention (I > mean, how much weight should my opinion hold?). At least, when a user comes > to me and says, "if this is crap, why is in the standard?" I can say, "beats > me, I tried to get it fixed, but no one cared." > > > Again, I think the entire problem comes from the fact that you > > don't really understand the purpose of a formal language > > definition, and that you read the word "requirement" in > > (to use your terms) "software engineering" sense, which is > > totally misleading in this context. > > Absolutely! An equally elegant solution to the problem to this would be to > put in the front of the standard: > > "WARNING: Terms used in this standard, such as 'requirement,' do not have > their usual English meaning." > > > (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? > > Sent via Deja.com http://www.deja.com/ Before you buy.