Re: limited types in libraries

[Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de>]

ada_wizard@toadmail.com wrote:
: Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:
: 
:> Sometimes I dearly wanted limited records but was defeated
:> by the library that could not store them (storing them was the
:> intention):
:> 
:>   type T(x: access D) is tagged limited private;
:> 
:> I want x to be constant plus initialised once and for all,
:> so access discriminants are just fine, but T has to
:> be limited then. Which would have been o.K., but not every library
:> allows this.
: 
: Just use the libraries that do; that's why there are more than one!

What I'm doing is I'm using several, for some reaons, currently
in seperate configurations.

One reason is that at the current (early) stage it helps me think
about what data I have, and how they interact, independent of
the implicit "design hints" that a library might entail.

Then there are the features and functions I need, and while
the offerings are rich, they are not equal so some work needs
to be done anyway.  Once you know a few bits about how STL works,
working with Charles is straight forward, and a lot is there,
but not everything. As the author says, it isn't completely done,
and so occasionally I stumble (for example assigning maps and then
using iterators (assignment was done in error, but still)).
BCs have graph support in a manner that fits parts of my
program very nicely.
So, I can use Charles containers for representing graphs,
and I can use BC's graphs directly. Both libraries have iterators,
so implementation of algorithms can be similar.

Then I want the libraries to be as invisible as can be, in
particluar they are banned from specs other than (my own program's)
*.Support.* packages.


:> What should I do? 
: 
: If the libraries that do allow limited items don't provide the
: functionality you need, help add it.

Difficult, see below.
 
: Or, talk to the authors of the libraries that don't allow limited
: items, but do offer the functions you want, about improving them.

If I had the money, I'd be glad give it to someone :-/
(From what I see, there might be a few things to consider when
a container is to be used with limited types. If you want to
reuse code from the "non-limited" container, how does a
"non-limited" container implmentation depend on comparison
and assignment of the element type (and key type, possibly).
What does it mean if a user supplied comparison function does
not fulfill a non-language requirement? (I think in Charles
it turns out to be a programmer's problem if he/she does not
implement "=" and "<" in a consistent manner for element/key.
(That is also true for STL's equivalents, IIRC.)))

: SAL (http://www.toadmail.com/~ada_wizard/) allows limited items, but
: is somewhat lacking in functionality compared to other libraries; want
: to help improve it?

Improving container libraries looks like really hard and admirable
skillful work, therefore I don't feel like I can be of great
help. (Let alone time...)  For example, when I ran into the above
mentioned Iterator problem when copying a (sorted) map, I found
myself following paths deep down into a red-black tree (implemented
following the first edition of Corman/Leiserson/Rivest is seems)
and wondering why some pointer was null, until I thought I had
discovered that Assign (I think) had not been done yet, it is
commented. Luckily I shouldn't have used assignment in the first
place, so this has actually helped me discover a "design bug" in
my program :-) However, to solve these kinds of problems in a library
it takes a programmer with more skills than I will every have,
I'm afraid.

But I will look at SAL (and the PragmARCs) when the program
has been assembled from its working pieces (in Charles and BC
configurations), in a second iteration to see whether the specs
are sufficiently abstract to allow an exchange of components.
I'll do that until there is a sufficient guarantee that some
library/ies will be provides with Ada :-)


-- Georg