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: <8f49je$pti$1@nnrp1.deja.com> X-Deja-AN: 620329447 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> <8f3s87$bsc$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x29.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 17:36:48 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: > 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.