Ada Container Library - Position Statement

As a practitioner in the avionics field, I've 'rolled my own' list generics more than once. It is frustrating to me that the language, already rich in other areas, is so obviously lacking in standard, basic data structures. I feel my previous experience is probably typical of the Ada user in the military field - not mission/safety critical but on the 'safer' side (statically sized lists, persistent, status rather than exception, etc).

While not sexy to admit, the majority of Ada use is probably still in the more conservative avionics industry and so any solution should remember this. At the same time, our mission must include the 'new flank' of the Ada users - the open source, commercial company. Therefore, any requirements must take heed of their 'unbounded' requirements. In this respect, I feel a solution partitioning along the lines of the current 'Ada.Strings' should be considered.

For some time, the participants in comp.lang.ada have been discussing the need for expanding the current definition of the Ada language to encompass new technologies and allow standard access to common container libraries. It is my view that without such components Ada, as a language, will wither on the vine, and more over that a solution is already at hand.

The Booch Components, as updated by Simon Wright, already provide a rich environment of data structures and may already deal with the thorny issues of licensing (they are under the "GMGPL"). The necessary boundary between high-integrity software and the more liberal requirements of commercial software (bounded versus dynamic/unbounded) is also covered. I do note that the current Booch implementation raised exceptions which may be unacceptable, but hopefully some sort of compromise may be available (i.e. compiler vendors are allowed to provide non-exception raising variants for implementations that require such packages).

For a detailed rationale of the Booch/Wright Components (BWC) please refer to "www.pogner.demon.co.uk/components/bc/". Briefly, it provides at its root a generic, abstract, controlled 'Container' tagged type. This type is extended in Child packages to provide abstract variations of container (Maps, Lists, etc). Storage Pool control is provided for all dynamic/unbounded variations via generic parameters to allow this control to be defined separately from the definition of the container. In its current form, the BWC are not complete but very close to being so.

I don't particularly mind *not* imposing performance requirements - this follows the standard advice given in these circumstances - take it up with your compiler vendor. If the vendor isn't helpful, change them! If a significant proportion of correspondence feel this is an issue, then could it perhaps for part of any 'Implementation Advice'?

Therefore, my list of requirements that such a container library should fulfil is:

1) Simplicity    - to allow the most widespread use
2) Efficient     - not as in 'Performance Requirements' but as in not specifing something with built-in inefficencies.
3) Extensibility - to allow more complex requirements to be met
4) Deterministic - to allow use in the mainstream of avionics use
5) Consistent    - to allow users to move from one package to another without having to re-learn everything

My list of requirements that I'm not bothered about is:
1) Built-in Concurrency Support - can be easily 'self rolled' on top
2) Performance Requirements     - too tricky!

I would hesitate to follow any development that did not carry with it a chance of real adoption and support from the compiler vendor community (will there be compiler vendor representation at the workshop?).

I'm happy to lend my personal time to help push this forward in any capacity (producing specifications, reference implementations, testing, documenting whatever, coffee maker!). I have already signed up to TED's 'Grace' web site on Savannah should that be considered a better proposal.

Martin Dowie