Re: Bases for the Design of a Standard Container Library for Ada

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

"M�rio Amado Alves" <maa@liacc.up.pt> wrote in message
news:4a4de33a.0309021059.53f71234@posting.google.com...
> I'm submiting this document to the Ada community as a request for
> comments:
>
>   BASES FOR THE DESIGN OF A STANDARD CONTAINER LIBRARY FOR ADA

What's missing in this document is a discussion of what the library is
trying to accomplish. You really have to have that before you can even talk
about other requirements.

If I was writing such a purpose statement, I would come up with something
like:

"The library is intended to provide a standard set of building blocks to
make it easier and faster to create the non-critical parts of applications."

Once a purpose statement is agreed to, you can evaluate technical
requirements based on it. For instance, my purpose statement would allow
drawing the following conclusions:
    -- Ease of use is paramount. There should be as few instantiations and
other complications as possible. (Ideally, exactly one, simple
instantiation.)
    -- "Non-critical" means that multiple versions of a component tailored
for specific patterns of use are not needed. When performance is critical,
the standard library is not intended to be used. (Build your own data
structures.) Note, however, that performance is rarely critical, so this
won't make much difference in practice.
    -- Similarly, concurrency protection isn't needed. (But any standard
library in Ada has to work from multiple tasks as long as the objects are
disjoint.)

And so on. I don't want to impose my statement on the process; it's just an
example. But I think we need such a statement with some level of agreement
before anything else can be (or should be) said.

(We do have to be careful of trying to make the standard library all things
to all people. That isn't possible, and we shouldn't be encapsulating a load
of complexity for that.)

                            Randy Brukardt.