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.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,43ff490aee692a6a X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-12-03 07:49:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!hub1.nntpserver.com!nntp-relay.ihug.net!ihug.co.nz!out.nntp.be!propagator-SanJose!in.nntp.be!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9ucgi0$7g2i6$1@ID-25716.news.dfncis.de> Subject: Re: ASCL project on AdaPower.net Message-ID: <1aNO7.46920$xS6.76554@www.newsranger.com> X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Mon, 03 Dec 2001 10:49:17 EST Organization: http://www.newsranger.com Date: Mon, 03 Dec 2001 15:49:17 GMT Xref: archiver1.google.com comp.lang.ada:17345 Date: 2001-12-03T15:49:17+00:00 List-Id: In article <9ucgi0$7g2i6$1@ID-25716.news.dfncis.de>, Nick Roberts says... > >I'm delighted to announce that a nascent ASCL (Ada Standard Component >Library) project has been set up at: I guess ASCL is OK as a placeholder, but the name was one of the things we were still debating. I'm on record against meaningless acronyms like ASCL. >http://www.adapower.net/ascl/ As to the "requirements" on that page: To make this more requirement like, all the "to be" verbs need to be changed to "shall" (indicating a must have) or "should" (indicating a nice-to-have). Unless otherwise stated, they need to be "shall"s. On 3, all of the "to be" verbs should be changed to "should"s. 5 and 7, and 8 are just flat-out wrong. (7 and 8 could be another "need not support"). 10 is really a new one about arrays. Since its a should, its phrased correctly. 12 is new. I'm not familiar enough with any such environments to know what this even means. 13 is also wrong. This should be changed to a "need not" (however we can phrase that in should/shall lingo). As a general comment, I notice a lot of stuff in that fourth column I'd disagree with. While some of this might be new for those who haven't been following the whole thread in all its various forms, pretty much everything in there has already been discussed to death and (IMHO) consensus arrived at. The exceptions to this are points 10 and 12. But both of them should probably be made "should"s, and in that form I don't think they are particularly contraversial either. Just to restate my position, I don't think we need a set of requirements to vote on (at least not these; new ones perhaps...). Instead, what we need a *the* set of requirements written down, where we can point newcommers (and possibly provide an explanation why). We certianly don't need the amount of "further dicussion" implied by the fourth column on that page. In fact, words cannot express how much we don't need that. :-) Here's what I think *is* still up for discussion. * The name of the facility. * How safe iterators need to be. I think consensus is starting to move to completely safe (for unbounded anyway). * The naming scheme for accessing the ends, and for iterating. * The precise subprogram-for-subprogram composition of the package spec. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html No trees were killed in the sending of this message. However a large number of electrons were terribly inconvenienced.