Version 1.4 of acs/ac-00030.txt

Unformatted version of acs/ac-00030.txt version 1.4
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?
!summary
!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: Robert Dewar
Sent: Saturday, April 27, 2002  9:36 AM

I assume everyone knows what a container is, and understands bag, set, list
etc semantics if they are going to participate in this discussion. What has
this observation to do with my question as to whether it makes sense for
this to be in the RM?

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

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

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

From: Alexandre E. Kopilovitch
Sent: Saturday, April 27, 2002   9:32 AM

Robert A Duff <bobduff@TheWorld.com> wrote:
> >... 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...

Well, that seems right way... Then, I conclude, Ada95 already has sufficient
features for standartization of the containers.
  After that conclusion, I think, the logical consequence is that: if there
exist several sufficiently widely used container libraries then they can be
reviewed, compared, and provide the basis for the standard. Otherwise, there
is neither real ground nor a real need for that standartization - the
non-standartized but widely used libraries should come first.

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

From: Michael Erdmann
Sent: Saturday, April 27, 2002  2:50 PM

Robert Dewar wrote:

>I assume everyone knows what a container is, and understands bag, set, list
>etc semantics if they are going to participate in this discussion. What has
>this observation to do with my question as to whether it makes sense for
>this to be in the RM?

Sorry, i was not sure!  But what is the creteria for putting something into
the  RM, e.g. why is Unbounded_String part of the Annex?  Theoretically
you  could leave the implementation of such things to the end user of a
complier, since the compiler does not have to provide any special
features for it.
So i guess  because there was some kind of demand for it is in the
Annex of the RM! I think the same applies to containers as well!

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

From: Robert Dewar
Sent: Saturday, April 27, 2002  4:47 PM

Simple enough, there were indeed formal revision requests from active
Ada users for string handling facilities. But none for general container
facilities. C acts as a refernce point here. C has string operations,
but no general container facilities. Among standardized languages, I
think only C++ has gone this far in standardized libraries.

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

From: Michael Erdmann
Sent: Sunday, April 28, 2002  5:50 AM

How is such a formal revision request issued and what are the qualification
creteria for sich a revision request?

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

From: Robert Dewar
Sent: Sunday, April 28, 2002  6:48 AM

The present tense is inappropriate here. I am talking about the Ada 9X
revision process, which first involved gathering requirement requests.
These documents are presumably still available.

Since further Ada language development is unfunded, I do not expect to see
any repeat of this formal process, nor do I think it likely that it will
be repeated.

For us, it is quite simple, we pay attention to what our customers want to
see, and also to what potential customers want. That's the only significant
input for us. A new version of the Ada standard would be interesting to us
only to the extent that it corresponded with this input. I would be surprised
if any other Ada vendor had a significantly different viewpoint.

We currently have filed several hundred suggestions that have been made
either by customers, or by internal ACT people (and a few that come from
outside), and we implement these as we have the resources to do so. As
you see each new release of GNAT contains a long list of enhancements and
improvements, and we certainly expect that process to not only continue,
but to expand and accelerate.

With respect to issues involving standard libraries, you can see our input.
It is expressed by the new units we provide with GNAT in the gnat hierarchy.
These reflect the capabilities that we see as most appropriate. We really
have not seen any specific interest in a general containers package, though
we have seen a couple of customers interested in the Booch components.

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

From: Michael Erdmann
Sent: Sunday, April 28, 2002  8:00 AM

Robert Dewar wrote:

>The present tense is inappropriate here.

Sorry sounding tense, was not my intention.

>I am talking about the Ada 9X
>revision process, which first involved gathering requirement requests.
>These documents are presumably still available.
>
>Since further Ada language development is unfunded, I do not expect to see
>any repeat of this formal process, nor do I think it likely that it will
>be repeated.

What will be the driving force to enhance Ada in the future?

>With respect to issues involving standard libraries, you can see our input.
>It is expressed by the new units we provide with GNAT in the gnat hierarchy.
>These reflect the capabilities that we see as most appropriate. We really
>have not seen any specific interest in a general containers package, though
>we have seen a couple of customers interested in the Booch components.

This approach is ok for libraries, but what is about further development
of the language?
Ada will have to pay its tribute to the changing  boundary conditions
for software development (e.g.  internet, java, mobility etc...)

Mean while i have changed my attitude regarding the container subject. I
still think it is an important issue, but it is simply a small part of larger
Problem. In the Ada 95 open source community every body seems to tinkering
arround writing smaller and larger support components, but a common
library project which concentrates these efforts into progress making project
does not exist. Since i am not the coding genius, i will concentrate my
effort on starting up such a project (http://ascl.sourceforge.net/).  People
working on this project are at the same time the customers, so i expect that
the result will resemble what is realy needed.   Lets see if containers are a
part of this library!

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

From: Tucker Taft
Sent: Sunday, April 28, 2002  3:21 PM

Michael Erdmann wrote:

> What will be the driving force to enhance Ada in the future?

Robert Dewar responded:

>> For us, it is quite simple, we pay attention to what our customers  want to
>> see, and also to what potential customers want. That's the only significant
>> input for us. A new version of the Ada standard would be interesting to us
>> only to the extent that it corresponded with this input. I would be surprised
>> if any other Ada vendor had a significantly different viewpoint.

I think the Ada Rapporteur Group as a whole has a slightly different
perspective than this.  We are not strictly driven by "paying customers."
We are also focused on the healthy process of language evolution
in response to changes in the computing community.  We are not
only interested in existing users of Ada, which are necessarily the
primary focus of a given vendor.  We are also interested in addressing
issues which may be barriers to the future or ongoing use of Ada.

In any case, sending concrete proposals to ada-comment@ada-auth.org
is the best way to get the attention of the ARG, which is responsible
for ongoing maintenance and amendment to the Ada standard.

It also doesn't hurt to have paying customers of Ada vendors
indicating support for your proposals.

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

From: Robert Dewar
Sent: Sunday, April 28, 2002  3:26 PM

<<In any case, sending concrete proposals to ada-comment@ada-auth.org
is the best way to get the attention of the ARG, which is responsible
for ongoing maintenance and amendment to the Ada standard.>>

But it is unlikely for the ARG to invent and propose extensions out of
nowhere, and if that starts happening, it will represent a breakdown
of the process in my view. We don't want to start cluttering the
language with miscellaneous nice-to-have features that do not have
a real constituency.

<<It also doesn't hurt to have paying customers of Ada vendors
indicating support for your proposals.>>

Indeed! A very important point, another viewpoint is that an extension
proposal is unlikely to succeed unless at least one vendor is inclined
to champion the proposal. For example, Unchecked_Union was pushed by
Aonix in the first place, and Unsuppress came from existing GNAT practice.

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

From: Simon J. Wright
Sent: Monday, April 29, 2002  2:23 AM

> From: Robert A Duff <bobduff@TheWorld.com>
[..]
> Well, you can pass an object of type Root_Storage_Pool'Class to a
> generic...

True (the Booch Components do this). What's not so easy is getting
hold of the default pool; I'm not comfortable with

   type T is access Integer; -- arbitrary subtype

   Pool : System.Storage_Pools.Root_Storage_Pool'Class renames T'Storage_Pool;

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

From: Alexandre E. Kopilovitch
Sent: Monday, April 29, 2002  10:19 AM

Indeed, I just looked briefly in RM, and found neither an approriate standard
(default) pool object nor an explicit statement about null'Storage_Pool .

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

From: Randy Brukardt
Sent: Tuesday, April 30, 2002   4:22 PM

That's because there is no such thing as the "default" pool. The standard
only says that a standard pool (let's use the RM terminology here) be used
in the absence of a specification of one. But there is no requirement that
the standard pool object be the *same* for all types. Indeed, an
implementation could use a different standard pool for each type, or for
each scope, or decide it based on the phase of the moon. See 13.11(17).

For example, Janus/Ada uses at least three different standard pool types:
the regular heap; a collection allocator (for types with storage_size
clauses), and one for allocating temporary objects. The latter two have many
different objects of those types (one per access type for the first, one per
scope for the latter). For us, we probably would declare the heap to be the
"standard" pool, but certainly we wouldn't want to insist that the default
pool always be that. (If we did, it wouldn't be possible to implement
Storage_Size as in the RM.)

So a single "default" pool object would be inappropriate. At most, we could
have a standard pool object, but there would be no requirement for
implementations to actually use it without specification.

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

From: Michael Erdmann
Sent: Wednesday, May 1, 2002  1:55 AM

Randy Brukardt wrote:

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

Please would some body care to explain has this relates to containers, i
am trying to follow, but i dont get the point?!!!

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

From: Simon J. Wright
Sent: Wednesday, May 1, 2002  2:34 AM

An unbounded container will need to allocate storage for its own use
(for example, you might use previous/next pointers to form a linked
list of cells, each holding one of the items the container is to
hold). The user needs control over how this storage is allocated.

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


Questions? Ask the ACAA Technical Agent