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,11acceb38e90ed0a X-Google-Attributes: gid103376,public From: Robert A Duff Subject: Re: Sequential_IO Data Portability Date: 2000/01/27 Message-ID: #1/1 X-Deja-AN: 578340751 Sender: bobduff@world.std.com (Robert A Duff) References: <38903e96@eeyore.callnetuk.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada Date: 2000-01-27T00:00:00+00:00 List-Id: "Nick Roberts" writes: > ... (I think RM95 M(69) implies this, but only very vaguely, and > Annex M is not normative). Annex M is not itself normative, but everything in Annex M refers to a normative paragraph somewhere else in the RM. If you want to see the real (normative) documentation rules, follow those references. > I think the next Ada revision should make an effort to enforce a level of > documentation. ... IMHO, that's not a good idea. You can't legislate good documentation. And trying to do so leads to all kinds of nonsense. For example, it leads to vendors thinking they've got good documentation when all they've done is barely obey some minimal rules. Ada 95 already goes too far in that direction. It's a complete waste, because the validation process doesn't bother to check the rules. >... Of course no automated tests could be used to verify this, > but human-level verification is perfectly practical. I'm not advocating a > densely beaurocratic approach. I think the right approach is "human-level verification", as you say, but then for those humans to gripe at their vendors if the documentation doesn't meet their needs. The language standards bodies and validation bodies shouldn't get involved in this issue. - Bob