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,LOTS_OF_MONEY, 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: <8f4av3$r6s$1@nnrp1.deja.com> X-Deja-AN: 620335527 References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <8es65n$5hn$1@nnrp1.deja.com> <%MoQ4.7915$wb7.556168@news.flash.net> <8eulom$u8m$1@nnrp1.deja.com> <3914F1DC.A5EE1751@earthlink.net> <8f3u36$dnk$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 18:00:12 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: > 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.