Re: limited types in libraries

Re: limited types in libraries

[ada_wizard]

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

Re: limited types in libraries

[Georg Bauhaus]

ada_wizard@toadmail.com wrote:
 
: 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.

Yes, but there might be different requirements in other parts
of a program, which let the programmer _think_ that "=" and "<"
are consistent.
A database's records of persons' addresses might be sorted by
surname, for example. Suppose name(r) returns a Wide_String or
similar for the surname in a record. Then one record is sorted
before another by

  function "<" (k1, k2: DB_Record) return Boolean is
  begin
     return name(k1) < name(k2);
  end "<";

(and similarly  for ">"). However, two records indicate the same person
if they show the same name and phone number,

  function "=" (k1, k2: DB_Record) return Boolean is
  begin
     return name(k1) = name(k2) and phone(k1) = phone(k2);
  end "=";

Then it might be that for j /= 0,
    not dbrec(n) < dbrec(n + j)
and not dbrec(n) > dbrec(n + j)
but still
  not dbrec(n) = dbrec(n + j)
and this might make sense from the point of view of database records.
So I might have to change my point of view so that I can see the
requirements of the containers or sorting related algorithms, and
understand, in some details, when "=" and "<" will come into play.

(But I might just be confused.)

-- Georg

Re: limited types in libraries

[ada_wizard]

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 should I do? 

If the libraries that do allow limited items don't provide the
functionality you need, help add it.

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

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?

-- 
-- Stephe

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

Re: limited types in libraries

[Georg Bauhaus]

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