Re: limited types in libraries

[ada_wizard@toadmail.com]

Georg Bauhaus <sb463ba@l1-hrz.uni-duisburg.de> writes:

> 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.

Ok. Then you are in a good position to help start The Final Ada
Library :).

> 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.

That's a good idea!

> : 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 :-/

Sometimes all it takes is someone showing an interest. Most of these
libraries were originally written for reasons other than money. Of
course, money never hurts :).

> (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). 

True. Which is why SAL was designed from the ground up to support both
limited and non-limited types, with the same generic containers.

> 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.)))

Hmm. I can't see why it would ever be ok to implement "=" and "<" in a
non-consistent way. Certainly any subprograms provided by the user
must meet the container's requirements.

> : 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...)  

Well, it is certainly harder than just using a working one. But it is
certainly worth doing.

Adding missing functionality to a well-designed library is easier than
starting from scratch.

And, simply proving feedback and motivation to the authors might be
enough. I know I'd be more willing to work on SAL if I knew people
were using it.

And finally, you should always spend some time challenging your
skills; that's the only way to improve them :).

> 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.

Hmm. If a subprogram is not implemented, it should raise an exception,
not silently do the wrong thing. You can fix that much, at least.

> 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.

Give it a try; you might surprise yourself.

> 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 :-)

Excellent. If you can, please post a summary of your experience with
these libraries. Maybe you'll inspire us to work together to do that
One Final Library, after all ...

-- 
-- Stephe

___________________________________________________________
This mail sent using ToadMail -- Web based e-mail @ ToadNet