Re: ASCL project on AdaPower.net

[Ted Dennison<dennison@telepath.com>]

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.