Re: status of Ada STL?

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

Marin David Condic wrote in message ...
>I'm curious about what you're looking for archtecturally? Some sort of
>breakdown of library domains? (e.g., "Containers", "Mathematics", "OS
>Services", etc.) A breakdown of implementation concepts? (Dynamic vs
Static,
>Generic vs Object Oriented, etc.) Or just a breakdown of desired
>functionality? ("A list container will have the following types,
operations,
>etc.")

Speaking for myself (not for the ARG!), I'd like to see an agreed on
list of requirements for the library. That would make it easier to
evaluate proposals/existing libraries.

For example, my number one requirement is ease-of-use. I expect the
primary use of these containers would be in prototypes and non-critical
code, and also by programmers relatively new to Ada. For those uses,
ease of use is more important than expressive power or top shelf
performance. After all, if it is harder to use the components than it is
to roll-your-own, no one will use them. (That is my objection to the
original Booch components - haven't looked at them recently).
Ada.Strings.Unbounded is designed that way, so it would be consistent to
do that with libraries as well.

>..
>Something the vendors would package with their compilers on an "As Is"
basis
>with the only promise being that most/all implementations of Ada come
with
>this library and the only guarantee is the package spec - behavior may
vary
>some.

That is not going to happen. Speaking for RR Software, if we provide it,
we're going to support it. If you want something else, get it from
AdaPower. We're not going to provide an "as-is" code. Period.

Moreover, I doubt that anything that doesn't have defined behavior is
going to be portable in any practical way. You're better off downloading
the code from AdaPower, because then you'll have the code, and it can be
ported (hopefully) without changes.

>This isn't far afield from what other languages have done in the past
>and continue to do ...

The best suggestion I've seen here is to provide a semi-official library
of code similar to Java's. This keeps the vendors out of it (beyond
making sure that the code compiles). And the user is not mislead about
the status of the code. The main question with this idea is who is going
to sponser it and fund it? That's being actively studied -- hopefully a
solution will be found.

                Randy Brukardt