CVS difference for ais/ai-30302.txt

Differences between 1.20 and version 1.21
Log of other versions for file ais/ai-30302.txt

--- ais/ai-30302.txt	2005/11/16 06:51:24	1.20
+++ ais/ai-30302.txt	2006/02/21 04:22:05	1.21
@@ -32938,3 +32938,585 @@
 
 ****************************************************************
 
+From: Matthew Heaney
+Sent: Tuesday, November 29, 2005  5:46 PM
+
+> The deadline for comments on Draft 14 was noon CST today (that is, 12 hours
+> ago). Don't bother with any more; future comments will have to be submitted
+> via WG9.
+
+I intend to submit the following comment to the WG9.  What is the 
+procedure for doing that?
+
+
+There is an issue with the latest AI-302 draft, concerning the signature 
+of the Splice operation for the list container.
+
+The operation is declared as follows:
+
+    procedure Splice (Container: in out List;
+                      Before   : in     Cursor;
+                      Position : in out Cursor);
+
+
+The purpose of this operation is to move elements within the same list. 
+Position specifies the element to move, and Before specifies to where it 
+moves.
+
+The issue is that the Position parameter is mode inout, not mode in. But 
+this is wrong, since the value of the Position cursor does not change 
+its value.
+
+The problem with the signature as it exists now is that it's impossible 
+to directly pass the result of a function as the value of the Position
+parameter. For example, to "rotate" elements in a list, you would like 
+to be able to say:
+
+   L.Splice (Before => L.First, Position => L.Last);
+
+This moves the last element to head of the list.  You could go the other 
+way, too:
+
+   L.Splice (Before => No_Element, Position => L.First);
+
+This moves the head of the list to the foot.
+
+To do this with the current signature, you have to declare a temporary 
+variable:
+
+   declare
+     C : Cursor := L.Last;
+   begin
+     L.Splice (Before => L.First, Position => C);
+   end;
+
+But this is much worse, because Position must be a variable, which means 
+that its value can change in between its declaration and the call to Splice.
+
+The only reason Splice is declared this way is because its semantics are 
+described as follows:
+
+   Equivalent to Splice (Target => Container, Before => Before,
+   Source => Container, Position => Position);
+
+The Splice operation to which the description refers is declared this way:
+
+    procedure Splice (Target   : in out List;
+                      Before   : in     Cursor;
+                      Source   : in out List;
+                      Position : in out Cursor);
+
+
+The fact that Position has mode inout makes sense in this case, since 
+this two-list version of Splice potentially moves the element designated 
+by Position from one list to another. (The representation of type Cursor 
+includes a reference to the container itself, so if the element moves to 
+a different container, then the cursor value must change.)
+
+But in the one-list version of Splice, the element stays within the same 
+container, so Position does not change its value. In fact, if an 
+implementation of Splice were to change the value of the Position 
+parameter then the implementation would be broken!  Yet the parameter is 
+still declared as inout.
+
+The only reason Splice is declared this way is because of the 
+*description* of the semantics, not because of the semantics per se. 
+The description, and the signature of the Splice operation, need to change.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Tuesday, January 24, 2006 12:53 PM
+
+Matt Heaney asked me to forward this to the ARG.  Has this already been taken
+care of in the latest draft?
+
+I'm not an expert on the Containers stuff, but it seems like he's correct
+about the mode.  True?
+
+[The attachment was the previous message - ED]
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 24, 2006  1:59 PM
+
+> Matt Heaney asked me to forward this to the ARG.  Has this already been
+taken
+> care of in the latest draft?
+
+Supposedly, the US will be sending this as a comment on the standard.
+(Remember, we're only taking comments from National Bodies now.) That hasn't
+happened yet, but when it does I'll update the standard appropriately.
+
+(That goes for all of the other non-editorial issues that have been
+discussed here since the letter ballot, too. They've all been forwarded to
+one country or another to make a comment.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, December 23, 2005  8:25 AM
+
+Here are a couple of editorial comments on Draft 15.
+I'll write more at some point...
+
+A.18.2(137.a/2)  ... the check prevent{s} data loss ...
+
+A.18.3(71/2) The wording for the semantics of "=" seems tortured and overly
+  procedural. 
+
+ Current wording:
+   ... Otherwise, it compares each element in Left to the corresponding
+   element in Right using the generic formal equality operator; if
+   element equality returns False, then the function returns False. If
+   the function has not returned a result after checking all of the
+   elements, it returns True.
+   
+ Simpler, alternative wording:
+   ... Otherwise, it compares each element in Left to the corresponding
+   element in Right using the generic formal equality operator.   
+   If any such comparison returns False, the function returns False; 
+   otherwise it returns True.
+   
+ Corresponding changes to other sections would be appropriate.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Friday, December 23, 2005  8:39 AM
+
+I don't think your new wording is equivalent to the current one.
+The current wording makes it clear that comparisons stop as soon as some 
+call to the equality operator returned false, while yours seems to imply 
+that every element is compared.
+
+OTOH, the current version starts by "it compares *each* element..."
+Should "each" be understood as "each and every"?
+What is the intent? It does seem silly to compare everything once you 
+know that the result is False.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Friday, December 23, 2005  5:16 PM
+
+I think it is clear that if equality returns True, then all comparisions 
+have been made.  Should we require that all comparisons are done, or are 
+(partially) done in some canonical order if False is returned?   I don't 
+think so.  It only matters if some equality operator called has side 
+effects, and I see that as a pathology.  So the behavior should be 
+unspecified. ;-)
+
+Merry Christmas and a Happy New Year to everyone.  (Happy Hanukkah too, 
+especially since Hanukkah overlaps both Christmas and New Year's.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, December 23, 2005  9:19 PM
+
+> I think it is clear that if equality returns True, then all 
+> comparisions have been made.  Should we require that all comparisons 
+> are done, or are (partially) done in some canonical order if False is 
+> returned?   I don't think so.  It only matters if some equality 
+> operator called has side effects, and I see that as a pathology.  So 
+> the behavior should be unspecified. ;-)
+>
+I agree with this suggestion (leave it unspecified)
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, January  2, 2006  6:35 AM
+
+I agree, and I think we should steal the wording from 4.5.2(24.1/1) for
+the various operators in A.18.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, January  2, 2006  7:03 AM
+
+Sounds reasonable to me
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January  2, 2006  2:44 PM
+
+I tried to "steal" the wording from 4.5.2, and ended
+up with what I proposed, after a little cleaning up.
+Do you have particular problems with the wording I
+proposed?
+
+
+--- here is what I proposed ---
+
+    ... Otherwise, it compares each element in Left to the corresponding
+    element in Right using the generic formal equality operator.
+    If any such comparison returns False, the function returns False;
+    otherwise it returns True.
+
+
+****************************************************************
+
+From: Gary Dismukes
+Sent: Monday, January  2, 2006 2:59 PM
+
+Your proposed wording seems to require that comparisons must be done
+on all components, disallowing short-circuiting, at least that's how
+it reads to me.  The wording in 4.5.2(24.1/1) makes it clear that
+short-circuit evaluation is permitted.
+
+****************************************************************
+
+From: Robert I. Eachus
+Sent: Monday, January  2, 2006  4:24 PM
+
+> I tried to "steal" the wording from 4.5.2, and ended
+> up with what I proposed, after a little cleaning up.
+> Do you have particular problems with the wording I
+> proposed?
+>
+> -Tuck
+>
+> --- here is what I proposed ---
+>
+>    ... Otherwise, it compares each element in Left to the corresponding
+>    element in Right using the generic formal equality operator.
+>    If any such comparison returns False, the function returns False;
+>    otherwise it returns True.
+
+Yes. It implies that all comparisons must be done, even if one returns 
+false.  The code to do that in most cases would be unnecessary.  How about:
+
+If Left and Right denote the same list object, then the function returns 
+True.  If Left and Right have identical lengths, and every element in 
+Left compares equal to the corresponding element in Right using the 
+generic formal equality operator, then the function returns True.  
+Otherwise the function returns False.  Any exception that is raised 
+during evaluation of element equality is propagated.
+
+I think that is both shorter and clearer than the current wording, but 
+retains the property that how often, and in what order the generic 
+formal equality operator is called is not specified when the function 
+returns false. Technically my wording goes a bit further and allows the 
+generic formal equality operator to be called if the lists are of 
+unequal lengths.  (Unless the actual package maintains a length for each 
+list, the natural implementation will be to compare elements until one 
+compares unequal or the end of one list is reached before the other.)
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, January  2, 2006  3:36 PM
+
+Good point.  I was adapting the wording from 4.5.2(21-24),
+but failed to notice the critical Corrigendum addition
+of 24.1.
+
+Here is an adaptation of 4.5.2(24.1):
+
+   The order in which the formal equality operator is called
+   for elements is unspecified. Furthermore, if the result
+   can be determined before calling the equality operator
+   on some elements, it is unspecified whether the equality
+   operator is called on those elements.
+
+This of course makes the description significantly longer
+than the original, when the goal was to simplify.
+
+Perhaps the following combined wording might be preferable:
+
+     ... Otherwise, it compares, in an arbitrary order,
+     the elements in Left to the corresponding elements
+     in Right using the generic formal equality operator.
+     If any such comparison returns False, the function returns False;
+     otherwise it returns True.  It is unspecified whether
+     all comparisons are performed if at least one returns False.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, January  3, 2006  7:18 AM
+
+I agree with Gary.  Your proposed wording fails to express the fact that
+short-circuiting is allowed, and that the comparisons occur in an
+unspecified order.  The words of 4.5.2(24.1) need to be copied verbatim
+somewhere in A.18.  This could be done either as a blanket statement in
+A.18 itself, or it could be repeated each time we describe an "="
+operator.  I would prefer the second option myself, but I gladly leave it
+to the Editor to decide what's best.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, January 18, 2006  6:27 PM
+
+The version of AI-302 that is posted at ada-auth says:
+
+!standard A.18 (00)        05-12-02  AI95-00302-03/17
+
+My question is:  Shouldn't the generic child procedure
+
+   Ada.Strings.Bounded.Hash
+
+be named Generic_Hash instead?
+
+The issue is what happens if there's a use clause for 
+Ada.Strings.Bounded.  It's nice to keep the namespace for generics 
+(Generic_Blah) different from the namespace for instantiations (Blah).
+
+Note too that the Bounded_String type is declared in 
+Generic_Bounded_Length, so you could make a consistency argument.
+
+Also, can someone confirm that the generic formal package name for
+
+   Ada.Strings.Wide_Bounded.Wide_Hash
+
+is indeed "Bounded" (and not "Wide_Bounded").
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Thursday, January 19, 2006  9:34 AM
+
+It's a bit late to be proposing name changes, as forming a consensus would
+inevitably delay the standard.
+
+> My question is:  Shouldn't the generic child procedure
+> 
+>    Ada.Strings.Bounded.Hash
+> 
+> be named Generic_Hash instead?
+> 
+> The issue is what happens if there's a use clause for 
+> Ada.Strings.Bounded.  It's nice to keep the namespace for generics 
+> (Generic_Blah) different from the namespace for instantiations (Blah).
+
+I have a hard time being excited about this problem.  If you have a
+use-clause that makes Hash directly visible, it's still the case that you
+can declare locally a function Hash, and it's going to win:
+
+	use Ada.Strings.Bounded;
+	function Hash is new Ada.Strings.Bounded.Hash;
+
+so the only thing you lose is the ability to use a shorter name for the
+generic in the instantiation.  Shrug, how many instantiations will you
+write anyway?  Note that there is no general convention in the RM to use
+Generic_ in the name of generics.  Maybe there should, but that's water
+under the bridge: think of Integer_IO for instance.
+
+> Note too that the Bounded_String type is declared in 
+> Generic_Bounded_Length, so you could make a consistency argument.
+> 
+> Also, can someone confirm that the generic formal package name for
+> 
+>    Ada.Strings.Wide_Bounded.Wide_Hash
+> 
+> is indeed "Bounded" (and not "Wide_Bounded").
+
+That's what the RM says.  This name is spectacularly unimportant, as it is
+only used in named associations when instantiating Wide_Hash.  Also note
+that the generic nested in Wide_Bounded is named Generic_Bounded_Length,
+not Generic_Wide_Bounded_Length, so we have a precedent.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 19, 2006 11:59 AM
+
+> Note that there is no general convention in the RM to use
+> Generic_ in the name of generics.  Maybe there should, but that's water
+> under the bridge: think of Integer_IO for instance.
+
+Not to mention the containers themselves: we have Ada.Containers.Vectors,
+not Ada.Containers.Generic_Vectors.
+
+So any consistency argument has no legs here.
+
+****************************************************************
+
+From: Bibb Latting
+Sent: Thursday, February 9, 2006  1:31 PM
+
+!topic Control over storage pool underlying Ada.Containers packages
+!reference Ada 2005 RMA.18(all)
+!from Bibb Latting 05-02-09
+!keywords Containers, Storage Pools
+!discussion
+ 
+The capability to use a derivation of root_storage_pool with a container
+is desired to provide flexibility in the management of the storage
+underlying the container.  This capability provides the opportunity for
+the user to optimize memory allocation for a given application, work-around
+fragmentation in the hardware mapping of memory, provide non-core memory
+allocation of the container, or to comply with safety/security issues.
+ 
+Please feel free to change the above discussion as desired.
+ 
+****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, February 9, 2006  1:58 PM
+
+The general consensus on this suggestion was that it
+is good, but would involve significant analysis to
+get it right at this point.  A recommendation was to
+leave it out of the standard, but encourage implementations
+to support the capability.  In general the Containers
+packages were designed to be a starting point, not
+the final story.  Ordered_ and Hashed_ might easily be
+augmented with numerous other capabilities, including
+"Bounded_...", "Protected_...", "Pooled_...", etc.
+So long as all the packages have nearly identical
+contents, it isn't too bad to have implementation-specific
+code at the point of the instantiation.  The large
+bulk of the user's code will depend only on the package
+contents, not its instantiation parameters, and reasonable
+portability can be preserved.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 9, 2006  3:22 PM
+
+The deadline for informal comments on Ada 2005 was last Friday. At this
+point, only editorial comments will be accepted. There may be an opportunity
+for formal comments at some point later in the future (although the primary
+effect of such comments would be to endanger the future of the Amendment and
+potentially of Ada itself).
+
+So, at the point we're primarily talking about future work (beyond Ada
+2005).
+
+In any case, there are a number of reasons that user-defined storage pools
+are inappropriate for the unbounded containers that Ada 2005 has:
+
+1) There is no good way to name the default storage pool. Thus, there is no
+good way to specify the default case of using the default storage pool. We
+definitely do not want to make instantiating these containers harder.
+
+Note that we tried early in the Ada 2005 process (see AI-300) to find a way
+to make the default pool available. However, it ran into opposition from
+some ARG members, who noted that some implementations used multiple default
+storage pools, tailored to the characteristics of the type. That model
+doesn't make it easy to name the default pool. The issue died because no
+solution that worked for such a model could be found.
+
+2) Although it's counter-intuitive, allowing user-defined storage pools
+makes the containers less safe. The containers are almost certainly going to
+be implemented as controlled types. If the storage pool has some method
+other than Deallocate for freeing memory (before the pool itself ceases to
+exist) -- and many user-defined pools do -- that could free memory belonging
+to container objects and subparts. When those objects are later finalized,
+the world will end, as the finalization information could very well have
+been destroyed. (For instance, Janus/Ada chains together controlled objects;
+if the memory is prematurely freed, those chains can be destroyed, and
+almost anything could happen, none of it good.)
+
+This problem cannot happen with the standard storage pool.
+
+One could try to mitigate this problem by trying to define when it would be
+safe to do premature deallocation, but such wording would also have the
+effect of banning useful implementation techniques (such as caching of
+nodes).
+
+We'd also have to add wording to take into account this possibility. That
+would make the containers *appear* less safe than they currently are, by
+adding additional cases of erroneous behavior. Some reviewers were extremely
+concerned about erroneous behavior of the containers, and we spent a lot of
+effort eliminating as much such behavior as possible.
+
+Aside: We'd also need wording to allow any operation to call Allocate, and
+to require the propagation of any exceptions it generates. We don't need
+special wording for the standard storage pool, because all it can do is
+propagate Storage_Error, and *any* operation in Ada is *always* allowed to
+do that. So no extra wording is needed.
+
+3) The unbounded forms can (and often have to) allocate pretty much any size
+or shape of memory as part of pretty much any operation. For instance, a
+vector container (depending on it's implementation) could allocate
+individual elements, small "chunks" of elements, or the entire data array of
+elements at one time. Putting limits on that would be inappropriate for the
+unbounded containers - we want to encourage innovative implementations.
+Thus, any pool used with the unbounded containers would need to allow
+arbitrary-sized allocations.
+
+The effect of (2) and (3) is that many useful storage pools couldn't be used
+in the context of the unbounded containers. A pool that is used to manage
+memory would be inappropriate; it could only manage memory when no container
+instantiation exists, and at that point no memory is allocated anyway. A
+pool that does not allow any size allocation also cannot be used. For
+instance, a pool that only allows specific sizes of allocations to eliminate
+fragmentation could not be used in the context of the unbounded containers.
+
+That doesn't leave many useful pools that could be used with the unbounded
+containers. A pool that simply records the memory use could be used, and an
+alternative heap could be used, but that's about it. That didn't seem like
+enough to be worth the additional complication.
+
+OTOH, it makes perfect sense for other forms of container to provide this
+sort of functionality. The intent (as Tucker pointed out) is that the
+containers in Ada 2005 provide a starting point for Ada containers, not be
+the end point. We certainly hope that additional forms of containers are
+developed for future use. (Hopefully, that would contain a solution to (1),
+as well.)
+
+One of the things that we'll be doing in future months is considering where
+we need future work. Certainly, there has been a lot of interest in other
+containers and other forms of containers (such as Bounded), so that will be
+considered. And, as these are separate packages, there is no need to wait
+another 10 years to standardize them. Moreover, these packages are
+relatively easy for implementers to provide, so I would expect that most
+implementers will do so. But we'll need energetic people (like Matt Heaney
+was for the current set of containers) to participate and draft all of the
+tedious wording needed. (A thick skin, to survive the constant nit-picking
+at their hard work, also is a prerequisite.)
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, February 9, 2006  4:54 PM
+
+>...The containers are almost certainly going to
+> be implemented as controlled types. If the storage pool has some method
+> other than Deallocate for freeing memory (before the pool itself ceases to
+> exist) -- and many user-defined pools do -- that could free memory belonging
+> to container objects and subparts.
+
+The container type has finalization.  The heap-allocated memory blocks do not
+(unless the actual element type passed in does).  So it would be OK
+to use a user-def pool, so long as the element type does not have
+controlled parts.
+
+Anyway, I agree with what Tuck and Randy said: allowing user-def pools is a
+good idea, but for the future (after Ada 2005).
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 9, 2006  5:10 PM
+
+Huh? If the heap-allocated blocks are linked together (certainly will be
+true in the list container, probably in most of the others too), when the
+finalization routine walks the blocks whose memory has been reused to free
+them, the results won't be pretty.
+
+We certainly don't want to be mandating implementations that don't include
+any links (that would be a major change for the unbounded containers, and
+would make it very hard to implement the intended semantics). So I don't see
+how one could expect such a pool to work at any time than when no container
+objects exist. And even that prevents node caching.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, February 9, 2006  5:53 PM
+
+Yes, you're right.  I was confused.
+
+****************************************************************
+
+

Questions? Ask the ACAA Technical Agent