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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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 A Duff Subject: Re: Required Metrics Date: 2000/05/03 Message-ID: #1/1 X-Deja-AN: 618787776 Sender: bobduff@world.std.com (Robert A Duff) References: <5DDO4.2237$wb7.194854@news.flash.net> <8ek4ea$5ta$1@nnrp1.deja.com> <390DC8AD.59B5EBEE@averstar.com> <8ep0k3$jlr$1@nnrp1.deja.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-05-03T00:00:00+00:00 List-Id: I think the answer to your original question is, "Yes, the Metrics are real requirements, but it's not clear exactly what they mean." In other words, it's a matter of judgement whether or not a given piece of text constitutes proper documentation. I would have to agree that a statement like, "Documentation not yet available" is a clear violation -- I can say that without defining precisely what the rule means. I strongly agree with Robert Dewar's statement that Documentation Requirements should not be in the standard, and I said so many times during the Ada 9X design. Many people, including Tucker, did not agree. And I think the Metrics are the worst sort of Documentation Requirements. Putting Doc Requirements in a standard shows confusion as to what standards are for. Standards are not about forcing or encouraging people to make high quality implementations. Standards are about encouraging uniformity. IMHO, of course. ;-) Furthermore, Doc Requirements distract implementors from the real goal, which is good documentation. Look at any vendors Doc Requirements documentation. You will usually see a long list of poorly organized snippets of confusing, out-of-context, information. > I get a queasy feeling when it seems that the Ada vendor community may not > be addressing requirements they don't like. First, it doesn't seem to be a > very "software engineering" oriented solution, given how Ada folks are > supposedly more "software engineering" oriented than users of other > languages. Second, how can anyone claim that an advantage of Ada is > standardization, if vendors don't have to follow parts of the standard that > are hard to implement, or that they just don't like? You have a point. However, in this particular case, if vendors fail to provide the required documentation, that has absolutely zero effect on portability. The advantage of having a standard is portability. So it's hard to get too excited about a rule in the standard that has no effect on portability. > I'd hope we all agree that a compiler that passes the validation suite, but > can't handle *any* other valid Ada program, is also in practice not useful > for users, and should be universally denounced as not compliant to the > standard. Sure. >... However, once we start down the path of ignoring the requirements > we don't like, we lose any right to complain about such a case. That would be a stronger argument if we were talking about some language feature. Eg, we all know Robert Dewar hates asynchronous transfer of control, but it would be annoying indeed if GNAT didn't implement it. Likewise, I hate modular types -- but of course I don't refuse to implement them in the AverStar compilers, and I don't insist on changing the rules to be more to my liking. These would be true even if the ACATS didn't test for these features. > It seems to me in the Ada83 days that AIs were used to develop and document > consensus on clarifications, etc. to the standard. Is this no longer used? The ARG still exists, and still generates AI's. I suspect that if you sent in a question saying "Are the metrics really required?", the ARG would issue a ruling saying, "Yes, of course, it says so in plain English." (I'm not sure of that; some people might use it as an opportunity to get rid of these silly rules. Some people might take the attitude that you can't require something unless you can precisely define it -- and thus declare the metrics to be meaningless gibberish.) On the other hand, if you asked, "What, exactly, do the metrics require?", the ARG would refuse to waste time trying to answer the impossible. So, whatever compiler it was that said "Documentation not yet available", send them a bug report. I wouldn't be surprised if it's our compiler. ;-) - Bob