CVS difference for acs/ac-00030.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00030.txt

--- acs/ac-00030.txt	2002/04/26 20:15:16	1.1
+++ acs/ac-00030.txt	2002/04/30 21:42:06	1.2
@@ -347,6 +347,16 @@
 
 ****************************************************************
 
+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
 
@@ -981,6 +991,246 @@
 > 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.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent