Version 1.1 of acs/ac-00030.txt

Unformatted version of acs/ac-00030.txt version 1.1
Other versions for file acs/ac-00030.txt

!standard A(1)          02-04-23 AC95-00030/01
!class amendment 02-04-18
!status received no action 02-04-23
!subject Enhancements of the predefined language library?
!appendix

From: Michael Erdmann
Sent: Sunday, April 14, 2002  9:11 AM

I like to know the procedure which leads to the extension of the
predefined language environment. I am asking this since i think
that there are some things missing to meet todays working
requirements.
 From my point of view the packages for lists and containers should
be added to the predefined langude environment Annex.

What would be the correct procedure to initiate this?

****************************************************************

From: Erhard Ploedereder
Sent: Tuesday, April 16, 2002  5:00 PM

Ideally, you could send a specific proposal for such packages
(specifications) with a bit of associated rationale to ada-comment.

Adding new, useful packages to the Ada API is one of major enhancements
to be considered for the next revision and we have called on the
community to suggest candidates.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, April 17, 2002  6:52 PM

The gist of Erhard's answer is correct. Certainly, we talked about
additional packages for Ada at the Columbia meeting (November 2000), and
concluded that we needed to call on the community to produce secondary
standards.

But I wonder if we really ever did this? Many people on comp.lang.ada seem
to be ignorant of this request, and certainly there doesn't seem to be
working groups springing up to handle many of the APIs needed (containers
being the one exception). Perhaps we need to republicize this call for APIs?

The reason for making this call is simply that the ARG does not have the
manpower to work through the details of APIs. The experience (so far) with
Ada.Directories is instructive. At this point, we have spent more than 8
hours of meeting time discussing details of this package. That's nearly
1/8th of all of the time from those meetings! This is obviously not an
efficient way to create annex packages for Ada.

I had been planning to propose a Sockets package for Ada, but the experience
with Ada.Directories suggests that this needs to be accomplished some other
way.

In any case, proposals should be detailed, preferably in the format of an
AI, and can be submitted here on Ada-Comment. For standard packages, the
best example is the Ada.Directories AI (AI-248,
http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-00248.TXT).
The !discussion section is important, as it gives the Rationale for the
design. This is even more important with a proposal from outside the ARG, as
we will need to be able to evaluate the design, and knowing why some scheme
was chosen will simplify that process. Also important is the !wording
section, which gives RM-style wording for the proposal. If that isn't given,
I or some other member of the ARG will have to write it, and that is an
issue both for budget and schedule reasons (doing so takes time and/or
money), and also for the precision of the proposal. Of course, even if you
do all of this, there is no guarantee it will be adopted or that we won't
rewrite it anyway. :-)

In any case, I'd be happy to provide mailing lists and/or web pages for
(informal) working groups if they need them, and I'd certainly be happy to
provide suggestions (on request) about the format of a proposal.

****************************************************************

From: Robert Dewar
Sent: Wednesday, April 17, 2002  8:52 PM

<<I had been planning to propose a Sockets package for Ada, but the experience
with Ada.Directories suggests that this needs to be accomplished some other
way.>>

There are two ways of creating annexes.

One have a small group cobble together something reasonably useful. Then
the language committee holds their noses, and wields the rubber stamp.

Two: vet such annexes with the same care that went in to the main language.
This will indeed take huge amounts of time, this is very difficult stuff
to get precisely semantically right.

****************************************************************

From: Randy Brukardt
Sent: Wednesday, April 17, 2002  9:13 PM

Absolutely right. And the first approach probably is most appropriate for
specialized things such as sockets and containers.

After all, that is essentially how the Ada.Strings facilities were handled.
Someone went off and designed something, the DRs made a few comments (a
couple which were pretty major), the designers updated it, and we adopted
it. There wasn't a line-by-line walk through it. After all, "good enough"
(as opposed to "perfect") is probably sufficient -- it certainly is for
Java.

****************************************************************

From: Alexandre E. Kopilovitch
Sent: Wednesday, April 17, 2002  9:39 PM

Oh well, thanks, now I understand why Ada.Strings facilities are the worst
thing in Ada I have seen so far.

****************************************************************

From: Michael Erdmann
Sent: Thursday, April 18, 2002  1:34 PM

I understand. May be you noticed a discussion going on in comp.lang.ada, which
goes in a lot of threads of topic, but i guess there will be a chance to get
some peoples mobilized to contribute on the container issue.

I will make a very basic proposal regarding containers till mid of next week.
The idea will be based on something i am using regular, but can tear the
concept apart as you wish. I like to get your reaction first before i publish
in comp.lang.ada which is a mutch more inhomogenius community.

Regarding the ignorant community, i lile to ask you to be a  more proactive by
asking regualry for input on certain major topics, e.g. containers, netwroking
interface etc.  May be this could be the starting point for a process jike the
jpc for java.

****************************************************************

From: Bernard Maudry
Sent: Thursday, April 18, 2002  11:54 AM

> I had been planning to propose a Sockets package for Ada, but the
> experience with Ada.Directories suggests that this needs to be
> accomplished some other way.

A Sockets package is now something too late or too low level, as most
developers would prefer 'real' communication packages like the distributed
annex or CORBA, which are already standardized.

It seems to me that it would preferable to focus the effort on what developers
would like to use now, in the future, or both, something like
- a XML interface,
- sorting packages,
- a regular expression package,
- an arbitrary precision integer calculation package,
- an environment variables package,
- and other useful utilities which will avoid to reinvent the wheel every day.

****************************************************************

From: Robert Dewar
Sent: Friday, April 19, 2002  6:25 AM

That's a false impression. We have had steady and wide spread requests for
a sockets package, now satisfied by GNAT.Sockets, which is a widely used
package.

****************************************************************

From: Michael Erdmann
Sent: Thursday, April 18, 2002  2:55 PM

Select a topic and send a query to the Ada community!

The sorting packages, i am not sure is this is worth the effort because most
commercial applications are using the instrinics sort functionality of an
underlying data base.

I would place the environment variable package in the class of an abstract
configuration interfaces, which i find very important to have anmd which are
completly missing.

****************************************************************

From: Robert Dewar
Sent: Friday, April 19, 2002  6:31 AM

> The sorting packages, i am not sure is this is worth the effort because
> most commercial applications are using the instrinics sort functionality
> of an underlying data base.

Again I disagree, a simple internal sort meets a completely different need.
The sorting packages we provide with GNAT (e.g. GNAT.Hsortg/a) are widely
used.

****************************************************************

From: Michael Erdmann
Sent: Friday, April 19, 2002 11:58 AM

This is intesting i did not explect this, but i was just about my
perspective on this issue!

****************************************************************

From: Ted Baker
Sent: Friday, April 19, 2002  7:03 AM

A really useful package to have widely available would be an implementation of
a generic dynamic associative mapping, from some domain of key values to some
range of objects. I have in mind something like SNOBOL tables, but able to live
within Ada's type structure. It would need to be reasonably fast for sparse key
domains, and support reasonably fast updates. In other words, it would amount
to some form of generic dynamic hash tables.

I can't count the number of times I could have saved a lot of time
and effort if I could just have instantiated such a structure.

It can be used to implement a set (i.e., the subset set of the
domain for which the map is currently defined), or a function.

With sets and functions, you can program anything.

****************************************************************

From: Pascal Obry
Sent: Friday, April 19, 2002  8:02 AM

I really agree here. I have used a countless number of time a mapping data
structure for fast key/value retrieval. Currently I'm using the one from LGL.

   http://lglwww.epfl.ch/Ada/components/adt/directory.html

A normalized package for Ada will be very good.

****************************************************************

From: Michael Erdmann
Sent: Friday, April 19, 2002 12:06 PM

>In other words, it would amount to some form of generic dynamic hash tables.

I gues this sound what i am working on currently.  A container is some box
where you can put in elements which are implementations of an
abstract  container_element_type.  The response of the container is
simply a key which you can reuse as a reference any where to retrieve the
objects you have stored. The only weekness of my current concept is that
the key is simply an natural number and not some kind of flexible key type.

The nice thing about this key is that you implement some kind of persitency
in this box by used a data base, files system or what so ever. If you can
ensure that the key does not change you can always recover the object from the
box.

****************************************************************

From: Jeffery Carter
Sent: Friday, April 19, 2002 10:35 AM

You might be interested in skip lists. They offer search, insertion, and
deletion in approximately O(log N) time. An implementation and reference are
available with the PragmAda Reusable Components; see adapower for a link.

****************************************************************

From: Pascal Leroy
Sent: Monday, April 22, 2002  8:37 AM

> I will make a very basic proposal regarding containers till mid of next
> week. The idea will be based on something i am using regular, but can
> tear the concept apart as you wish. I like to get your reaction first
> before i publish in comp.lang.ada which is a mutch more inhomogenius
> community.

My recommendation, rather than reinventing the wheel, would be to look at
existing public domain code that has been around for years (for containers
the so-called Booch components come to mind, although there are probably
others), and try to formalize its definition (make it portable, clarify the
semantics, etc.).  At least we will know that this is stuff that is useful,
and for which an implementation exists.

****************************************************************

From: Michael Erdmann
Sent: Monday, April 22, 2002  3:06 PM

I know, there are a lot of usefull implementations existing, no question about
this! But when i look into the Ada 95 RM i find nothing. As a consequence i
have always reinvent the wheel,  since i have to look at a different place, get
the software, find the documentation , find the maintainer if he is still
existing, test the stuff etc. This is to time consuming!!!

More then 10 Years ago i was using the first time Smalltalk in a project, and
they provided something like these basic containers, 10 years later it is still
missing in Ada!?

If we can get such things in the Ada 95 RM then compiler maintainers will
distribute such packages and i dont have to worry about it any more and the
code might stay portable!

I dont like to start an accademical discussion about the theroy of an ideal set
of containers. My intention is to get at least some basic support for very
simple containers into the Ada 95 RM!  A good starting point was the discussion
about the hash tables last week, which is verry near so some requirement i have
regualry! I have mode today a proposal on this.

What do you mean by "..try to formalize its definition..."? What are you
expecting from me?

****************************************************************

From: Robert Dewar
Sent: Monday, April 22, 2002  6:38 PM

It is far from obvious that this should be in the RM. Many think that the
STL was a mistake in C++, it's certainly not something that you just follow
blindly without discussion.

Please use specific subject lines

****************************************************************

From: Pascal Leroy
Sent: Tuesday, April 23, 2002  2:14 AM

I share this concern.  If somehow we could come to an agreement on a library
of containers (and we are nowhere close to that), it would make more sense
to turn it into a secondary standard.  But even so, it is not quite clear
that the benefits of standardization would pay for the cost/complexity of
the standardization process.

****************************************************************

From: Michael Erdmann
Sent: Tuesday, April 23, 2002  2:11 AM

>It is far from obvious that this should be in the RM. Many think that the
>STL was a mistake in C++, it's certainly not something that you just follow
>blindly without discussion.

A container (bag) is the abstraction of a storage which allowes you to store
any object. As a response it returns an identifier which you can use to
retrieve the object. This allows you to implement algorithms on top of it
independant of the actually used storage media (arrays, files etc..).

I dont know C++ to well, what is the problem with the STL?

****************************************************************

From: Michael Erdmann
Sent: Monday, April 22, 2002  3:20 PM

Hallo all,

based on the discussion of last week i have prepared a small
proposal for a so called keyed_container.

http://home.snafu.de/~boavista/containers/

The main idea that there is a abstract base class container_element_type
and Key_Type. The container stores objects derived from
container_element_type
with keys derived from Key_Type.

This also includes a small test implementation, not perfect
but at least is does what i expect it to do!

****************************************************************

From: Pascal Leroy
Sent: Tuesday, April 23, 2002  2:11 AM

> What do you mean by "..try to formalize its definition..."? What are you
> expecting from me?

Well, you expressed interest in adding container packages to the RM.  Fine.
If you want something to happen, you have to come up with a proposal.  This
proposal must include some Ada packages (you already have that) together
with documentation detailing the semantics of the stuff declared these
specifications.  A rationale would also be good, as it would explain the
intended use of the packages, and clarify what alternatives were considered
and why they were discarded.  For the description of the semantics, look at
any of the predefined units currently in the RM.  For the rationale, look at
any amendment AI currently in the works.

At any rate, two-line comments in an Ada specification do not come close to
a semi-formal definition of the packages and their purpose.

> I know, there are a lot of useful implementations existing, no question
> about this! But when i look into the Ada 95 RM i find nothing.

The point I was trying to make is that, if you started from existing
libraries (perhaps modifying them if needed) you would be much likely to be
successful in having them included in the RM.  The reason is that we all
know that these libraries have been around for a number of years, their
semantics are pretty well understood (if only because there are reference
implementations) and they have proven useful for a variety of usages.  So
the project of standardizing them is "merely" a documentation project.

By starting from scratch with your own set of containers, you run the risk
that people will look at your proposal and decide that it doesn't meet the
actual needs.  For instance, when I look at the code that you posted
yesterday, I see that it assumes that the container element has to be
derived from some abstract type (Container_Element_Type).  To me, this
instantly kills the proposal, because the absence of multiple inheritance in
Ada makes it extremely hard to integrate existing type hierarchies with your
proposed containers.  To take another example, your proposal is strongly
oriented toward a hash-based implementation, and that's certainly not
appropriate for all applications (think of stacks, lists, AVL trees, etc.).

****************************************************************

From: Robert Dewar
Sent: Tuesday, April 23, 2002  6:28 AM

> The point I was trying to make is that, if you started from existing
> libraries (perhaps modifying them if needed) you would be much likely to be
> successful in having them included in the RM.  The reason is that we all
> know that these libraries have been around for a number of years, their
> semantics are pretty well understood (if only because there are reference
> implementations) and they have proven useful for a variety of usages.  So
> the project of standardizing them is "merely" a documentation project.

Pascal is absolutely on target here. One thing to ask is "why put anything
in the RM at all?" The answer is presumably that it will make implementations
more uniform. Now more uniform is not necessarily the same thing as more
useful. Indeed there can be a conflict between these two goals.

If implementors spend time implementing packages that their users do not
require (if they required them, they would already be there), then they do
this at the expense of not doing something else.

So an interesting question for those who want to add these additional
constraints is "what is it that implementors are doing now that you
wish them to stop doing".

I suspect that those who spend time trying to expand the standard think that
this is a mechanism for getting sometning they do not have now with no cost.
That's never true since this is a zero-sum game in terms of total resources.

One can imagine a new standard for Ada 2005 with all sorts of wonderful
packages in it.

What would be the effect of this standard?

Would anyone implement it?

Not clear for instance that Ada Core Technologies would. It would depend
on what our customers wanted. So far, many of our customers are still
running Ada 83, and only making small deliberate steps towards incorporating
Ada 95 features -- this seems perfectly reasonable to me. In the world of
hobbyists, everyone wants to fiddle with the latest stuff, but in the world
of real apps, people are far more conservative.

If you look around, you find that in the case of other languages, it can
take ages for general acceptance and implementation of new standard versions.
Look for example at Fortran 90.

I would hate to see lots of people put in a lot of effort on a new Ada
standard that basically got ignored by both Ada vendors and serious users.

That's why I think that it is far better for people to put their short
term effort into implementing and promulgating useful libraries. Get
users first, then get vendors signed up to support these packages,
THEN standardize.

The model of "design out of whole cloth", "standardize", then "implement"
is simply not the right one for these add on packages.

So Michael, don't think of your proposed container package as a candidate
for standardization yet, that's premature. Instead publicize it widely
and try to get people to use it. If people won't use it, then drop it,
you have not made it to first base.

If you can get serious Ada users to use it, then they will apply pressure
to vendors "Gee, we really like GNAT, but it does not implement the NOBBLETS
package, which we really need, what can you do for us, we need a supported
version of NOBBLETS and we have $$$$". Now *that* get's our attention :-) :-)

****************************************************************

From: Dave Emery
Sent: Tuesday, April 23, 2002  9:04 AM

Robert makes a good argument, but it's worth noting that part of the
popularity of Java is due to its large, predefined (i.e. "standardized")
set of useful components.  For many people I've talked to, they see the
standard Java libraries as being more important/useful to get real work
done than the language itself.

The notion of an "API registry" that provides some of the benefits of
standardization, without the significant overhead of the standardization
process, might well be worth doing.

****************************************************************

From: Robert Dewar
Sent: Tuesday, April 23, 2002  1:46 PM

<<Robert makes a good argument, but it's worth noting that part of the
popularity of Java is due to its large, predefined (i.e. "standardized")
set of useful components.  For many people I've talked to, they see the
standard Java libraries as being more important/useful to get real work
done than the language itself.
>>

Not even the Java language is standardized.

If you want to talk about things equivalent to Java you might as
well consider the GNAT library which is implemented on many targets.

Sure a large library is useful, but I think that if you tried to make
an ISO standard for Java you would have a heck of a time with the huge
miscellaneous mess of libraries that is currently part of Java.

I have nothing against a huge miscellaneous mess of libraries. I say, go
out there and help build one for Ada (and if it has identifiers that don't
meet Florian's notions of purity, don't worry about it too much :-)

By the way, is it beyond anyones capabilities to set proper subjects. This
discussion is about general library issues, not containers specifically :-)

****************************************************************

From: Michael Erdmann
Sent: Tuesday, April 23, 2002  3:25 PM

Pascal Leroy wrote:

>>What do you mean by "..try to formalize its definition..."? What are you
>>expecting from me?
>>
>
>Well, you expressed interest in adding container packages to the RM.  Fine.
>If you want something to happen, you have to come up with a proposal.  This
>proposal must include some Ada packages (you already have that) together
>with documentation detailing the semantics of the stuff declared these
>specifications.  A rationale would also be good, as it would explain the
>intended use of the packages, and clarify what alternatives were considered
>and why they were discarded.  For the description of the semantics, look at
>any of the predefined units currently in the RM.  For the rationale, look at
>any amendment AI currently in the works.
>
>At any rate, two-line comments in an Ada specification do not come close to
>a semi-formal definition of the packages and their purpose.

Thanks, now i have a program something to work on, i will do so!

>>I know, there are a lot of useful impementations existing, no question
>>about this! But when i look into the Ada 95 RM i find nothing.
>>
>
>The point I was trying to make is that, if you started from existing
>libraries (perhaps modifying them if needed) you would be much likely to be
>successful in having them included in the RM.  The reason is that we all
>know that these libraries have been around for a number of years, their
>semantics are pretty well understood (if only because there are reference
>implementations) and they have proven useful for a variety of usages.  So
>the project of standardizing them is "merely" a documentation project.
>
>By starting from scratch with your own set of containers, you run the risk
>that people will look at your proposal and decide that it doesn't meet the
>actual needs.

This the point which is also my problem. I am not sure if it will be possible
at all to provide a container package which suites everybody. If the look at
the respective threads in comp.lang.ada the number of comments exceeds
defenitly the number of lines of code which such a package would have.

>For instance, when I look at the code that you posted
>yesterday, I see that it assumes that the container element has to be
>derived from some abstract type (Container_Element_Type).  To me, this
>instantly kills the proposal, because the absence of multiple inheritance in
>Ada makes it extremely hard to integrate existing type hierarchies with your
>proposed containers.

I assumed that some one  would integrate own types as extending the base type.
I am using sich constructs regulary, please could you give me a small example?

>To take another example, your proposal is strongly
>oriented toward a hash-based implementation, and that's certainly not
>appropriate for all applications (think of stacks, lists, AVL trees, etc.).

There i agree completly, it was not intended to support these features. The
container package is a simple bag where you can store things in and the
keyed_container is a container  which allowes to store key/data pairs.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, April 23, 2002  8:07 PM

> I assumed that some one would integrate own types as extending the base
> type. I am using sich constructs regulary, please could you give me a
> small example?

That is only an effective way to program if you are creating the entire set
of types from scratch. If you are adding a new feature to a 20-year old Ada
compiler, redoing the entire set of types to use a keyed map isn't an
option.

For another example, consider a GUI builder written in Claw (or some other
standard binding). You may want a bag of window objects to hold onto the
various top-level windows in the system. (This is an unordered collection.)
Since there are multiple kinds of windows, this is obviously a class-wide
collection. Now, obviously, you aren't going to rewrite the types in Claw in
order to fit them into your bag container. Moreover, you cannot declare the
window object as a component of your element type extension either. So you
would have to use an access to the window object, meaning that you've
brought in all of  the complexity of heap allocation where there was none
before. At this point, there is no longer any benefit to using your
container (it's easier to just write a basic linked list).

That's why most container libraries for Ada are generic. Since Ada doesn't
have multiple inheritance, and it doesn't have a common object root type
like Java, to get something useful you have to make it generic. Otherwise,
you are just too constrained on the types that you can use.

****************************************************************

From: Robert Dewar
Sent: Tuesday, April 23, 2002  8:15 PM

> That's why most container libraries for Ada are generic. Since Ada doesn't
> have multiple inheritance, and it doesn't have a common object root type
> like Java, to get something useful you have to make it generic. Otherwise,
> you are just too constrained on the types that you can use.

I agree with Randy here.

****************************************************************

From: Michael Erdmann
Sent: Wednesday, April 24, 2002 10:51 AM

Randy Brukardt wrote:

>>I assumed that some one would integrate own types as extending the base
>>type. I am using sich constructs regulary, please could you give me a
>>small example?
>>
>
>That is only an effective way to program if you are creating the entire set
>of types from scratch. If you are adding a new feature to a 20-year old Ada
>compiler, redoing the entire set of types to use a keyed map isn't an
>option.

On this i completly agree. From my experience with OO Systems this one of the
major problems with Ada (Java has the same problem, thex got int and Integer
types).  It was not my intention, that you can put a integer straight into the
container.  But i think there is also a way of doing this by means of streams,
but i never thought about it.

Since containers impose some kind of overhead, my intention was never to put
basic Ada types into a container.

>For another example, consider a GUI builder written in Claw (or some other
>standard binding). You may want a bag of window objects to hold onto the
>various top-level windows in the system. (This is an unordered collection.)
>Since there are multiple kinds of windows, this is obviously a class-wide
>collection. Now, obviously, you aren't going to rewrite the types in Claw in
>order to fit them into your bag container. Moreover, you cannot declare the
>window object as a component of your element type extension either. So you
>would have to use an access to the window object, meaning that you've
>brought in all of  the complexity of heap allocation where there was none
>before. At this point, there is no longer any benefit to using your
>container (it's easier to just write a basic linked list).

I am not sure if you are right about the linked list, since you have to define
somewhere a type which has the properties of a list:

type Window_Collection is record
      w     : GUI_Window_Type;
      next  : Window_Collection_Access
   end record;

In case of a the base type container_element you have to do the same thing.

   type Window is new Container_Element with record
           w : GUI_Window_Type.
       end record;

with the difference that i dont have to care any more about the
correct implementation of the list. It is part of the container
package.

Regarding the access types and the heap allocation i am only agreeing
partially. You are right, i have to use some kind of Constructor
function:

    function Construct(
       w : GUI_Window_Type ) return Container_Element.Handle.

This is something realy arteficial i dont like to mutch. My be
a will add a generic helper function for this.

I accept that there will be mission critical applications where you dont like
to rely on a storage system with unspecified internal behaviour. Then it realy
makes sense to implement a list, since you can ensure the quality for this
software part within your own organisation. But in all other cases, the
perception of the development community of heap allocation is not any more as
an additonal complexity, it is understood as a help full thing and it is simply
used.

In order to get the allocation/deallocation under control i am
requiereing the implementation of the Duplicate and Destroy
function. These procedues can implement a resonable secure
allocation/deallocation scheme.

>That's why most container libraries for Ada are generic. Since Ada doesn't
>have multiple inheritance, and it doesn't have a common object root type
>like Java, to get something useful you have to make it generic. Otherwise,
>you are just too constrained on the types that you can use.

May be i will build a small wrapper around it which provides an
interface for generic types.

****************************************************************

From: Randy Brukardt
Sent: Thursday, April 25, 2002  4:27 PM

> I am not sure if you are right about the linked list, since you have to
> define somewhere a type which has the properties of  a list:
>
> type Window_Collection is record
>       w     : GUI_Window_Type;
>       next  : Window_Collection_Access
>    end record;
>
> In case of a the base type container_element you have to do
> the same thing.
>
>    type Window is new Container_Element with record
>            w : GUI_Window_Type.
>        end record;
>
> with the difference that i dont have to care any more about the
> correct implementation of the list. It is part of the container
> package.

No, neither of these are legal. Remember, the problem was that the element
type is classwide. (Root_Window_Type'Class in Claw). It is illegal in Ada to
declare such a component.

You are right that a simple linked list wouldn't work either; I'd probably
use an array of accesses to do it.

But my point is, once you've gone through the effort to allocate and
deallocate these things manually, there really isn't any advantage to the
container.

One reason that I almost never use (existing) container packages is that the
effort to using them is as much or more than simply writing a linked list.
The Booch components are particularly bad that way. In addition, a list is a
lot more flexible - if your bag turns into a stack, that is likely to be a
few minor changes to the code if it is a list; but changing a Bag component
to a Stack component often means changing most if not all of the calls (the
interfaces are rarely very consistent). And getting a list implementation
wrong in any manner that is not immediately obvious (with the possible
exception of a couple of rarely used operations) is unlikely for an
experienced programmer.

I'd prefer components that could be used as easily as Ada.Strings.Fixed.
Like a simple component, this package provides a lot of operations that are
easily written yourself. But, you aren't required to use it for everything,
so you only have to use the handful of operations that are "hard". That
makes it a lot easier to "ease" into using it; the learning curve is rather
low (you only need to know that a useful capability is there).

I realize that it probably isn't possible to make useful components that are
as flexible as Ada.Strings.Fixed, but I believe that needs to be the goal.

> But in all other cases, the perception of the development community
> of heap allocation is not any more as an additonal complexity, it is
> understood as a help full thing and it is simply used.

My concern is less that you need to use the heap, than that you need to use
the heap *explicitly*. Explicit uses of the heap are going to be more
error-prone than ones encapsulated solely within the component. That is
especially true in Ada, as you need to explicitly manage the deallocation of
the items. (Claw does not require the user to use the heap explicitly at
all, although the user is free to do so if they wish. But there is plenty of
heap use in its implementation.)

****************************************************************

From: Michael Erdmann
Sent: Friday, April 26, 2002 10:41 AM

Randy Brukardt wrote:

>>I am not sure if you are right about the linked list, since you have to
>>define somewhere a type which has the properties of  a list:
>>
>>type Window_Collection is record
>>      w     : GUI_Window_Type;
>>      next  : Window_Collection_Access
>>   end record;
>>
>>In case of a the base type container_element you have to do
>>the same thing.
>>
>>   type Window is new Container_Element with record
>>           w : GUI_Window_Type.
>>       end record;
>>
>>with the difference that i dont have to care any more about the
>>correct implementation of the list. It is part of the container
>>package.
>>
>
>No, neither of these are legal. Remember, the problem was that the element
>type is classwide. (Root_Window_Type'Class in Claw). It is illegal in Ada to
>declare such a component.

Sorry, i dont know Claw this mutch, but i gues you are refering to the fact
that the lists above con only store elements of the same type and not elements
of any type derived from the Root_Window_Type. It seems to me, that in Ada
because of the missing root type, it is only possible to support lists
containing the same type unless you accept the usage of class wide pointers
with all consequences.

>You are right that a simple linked list wouldn't work either; I'd probably
>use an array of accesses to do it.

I agree, but then you should not use a container.


>But my point is, once you've gone through the effort to allocate and
>deallocate these things manually, there really isn't any advantage to the
>container.

There might be an advantage to have to abstraction of a container. Take you
array example above. The algorithm using this array will have every where
references to the array contants  variable(x).... If i would like to reuse you
algorithm but without using the array for some reason then i would have to
change the source code. If a container is understood as an abstraction towards
the underlying storage, then you might develope alogorithm independant of the
presentation of the underlying memory.

But you are completly right, regarding the costs in reources.  There will be a
lot of situations where the effort is not worth the gain in it.


>One reason that I almost never use (existing) container packages is that the
>effort to using them is as much or more than simply writing a linked list.

I agree here as well. May be it is a better aprock to develop more small
adhock components the the package which is super abstract and difficualt
to use!

>The Booch components are particularly bad that way. In addition, a list is a
>lot more flexible - if your bag turns into a stack, that is likely to be a
>few minor changes to the code if it is a list; but changing a Bag component
>to a Stack component often means changing most if not all of the calls (the
>interfaces are rarely very consistent). And getting a list implementation
>wrong in any manner that is not immediately obvious (with the possible
>exception of a couple of rarely used operations) is unlikely for an
>experienced programmer.

I am realy wondering how successfull theses components are?


>I'd prefer components that could be used as easily as Ada.Strings.Fixed.
>Like a simple component, this package provides a lot of operations that are
>easily written yourself. But, you aren't required to use it for everything,
>so you only have to use the handful of operations that are "hard". That
>makes it a lot easier to "ease" into using it; the learning curve is rather
>low (you only need to know that a useful capability is there).
>
>I realize that it probably isn't possible to make useful components that are
>as flexible as Ada.Strings.Fixed, but I believe that needs to be the goal.

I agree completly.

>>But in all other cases, the perception of the development community
>>of heap allocation is not any more as an additonal complexity, it is
>>understood as a help full thing and it is simply used.
>>
>
>My concern is less that you need to use the heap, than that you need to use
>the heap *explicitly*. Explicit uses of the heap are going to be more
>error-prone than ones encapsulated solely within the component. That is
>especially true in Ada, as you need to explicitly manage the deallocation of
>the items. (Claw does not require the user to use the heap explicitly at
>all, although the user is free to do so if they wish. But there is plenty of
>heap use in its implementation.)

I also agree on this, but it does not stop me to use the heap.

****************************************************************

From: Pascal Leroy
Sent: Friday, April 26, 2002  1:30 AM

> One reason that I almost never use (existing) container packages is that
> the effort to using them is as much or more than simply writing a linked list.

I have mixed feelings about this comment.

On the one hand, it is true that many of these components are very shallow
abstractions which provide little value and might as well be implemented
from scratch when need be.  The textbook examples of (array-based) stack,
linked list, etc. certainly fall into that category.

But on the other hand, this is not true of more elaborate data structures
like the various flavors of balanced trees, or skip lists.  There is real
meat there, and I surely don't want to rewrite the rebalancing procedure of
AVL trees each time I need an efficient container.  Gee, I am not even
capable of writing a binary search in a sorted array without copying it from
Knuth.

In addition, a very important property of (well designed) container packages
is that they encapsulate the storage management operations (using controlled
types), and this reduces dramatically the likelihood of getting dangling
references or storage leaks.

I guess I am saying that containers only make sense if they encapsulate a
significant amount of complexity.  But that's stating the obvious, isn't it?

****************************************************************

From: Alexandre E. Kopilovitch
Sent: Friday, April 26, 2002  11:02 AM

"Pascal Leroy" <pleroy@rational.com> wrote:
>Gee, I am not even
>capable of writing a binary search in a sorted array without copying it from
>Knuth.

By the way, why not give some status of Ada standartization to some parts of
the Knuth volumes? I can easily imagine something like Ada.Knuth package hierarchy.

>In addition, a very important property of (well designed) container packages
>is that they encapsulate the storage management operations (using controlled
>types), and this reduces dramatically the likelihood of getting dangling
>references or storage leaks.
>
>I guess I am saying that containers only make sense if they encapsulate a
>significant amount of complexity.  But that's stating the obvious, isn't it?

Perhaps something in that isn't so obvious (as we still have no standard
containers in Ada). Possibly Ada lacks a language element good enough for
_standard_ implementation of the containers. I just imagined a candidate for
this purpose: a "virtual pool", that is, an entity that fully resembles an
Ada pool, but does not allocate its own memory, and use the standard system
pool (or explicitly assigned Ada pool) instead.

****************************************************************

From: Robert A. Duff
Sent: Friday, April 26, 2002  11:53 AM

Alexandre E. Kopilovitch" <aek@vib.usr.pu.ru> wrote:

> By the way, why not give some status of Ada standartization to some parts of
> the Knuth volumes? I can easily imagine something like Ada.Knuth package hierarchy.

Written in MIXAL, using machine-code inserts, of course.  ;-) ;-)

> >I guess I am saying that containers only make sense if they encapsulate a
> >significant amount of complexity.  But that's stating the obvious, isn't it?

I would state it differently: The amount of complexity encapsulated must
be larger than the amount of complexity in the interface -- e.g., if you
have to write 17 lines of instantiations to use the thing, it's probably
not worth it if the body of the generic is only 5 lines.

> Perhaps something in that isn't so obvious (as we still have no standard
> containers in Ada). Possibly Ada lacks a language element good enough for
> _standard_ implementation of the containers.

Well, Ada is not perfect, but you can do a lot in this direction with
generics.  An approach that requires inheriting from a particular type
is not a good idea, but that's not the only approach.

>... I just imagined a candidate for
> this purpose: a "virtual pool", that is, an entity that fully resembles an
> Ada pool, but does not allocate its own memory, and use the standard system
> pool (or explicitly assigned Ada pool) instead.

Well, you can pass an object of type Root_Storage_Pool'Class to a generic...

****************************************************************


Questions? Ask the ACAA Technical Agent