!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 <> 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 <> 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" 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" 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 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 <> 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. <> 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 [..] > 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. ****************************************************************