CVS difference for ais/ai-20302.txt
--- ais/ai-20302.txt 2004/02/04 00:49:19 1.1
+++ ais/ai-20302.txt 2004/02/06 05:01:50 1.2
@@ -1,4 +1,4 @@
-!standard A.17 04-02-02 AI95-00302-03/01
+!standard A.17 04-02-05 AI95-00302-03/02
!class amendment 04-01-14
!status work item 04-01-14
!status received 04-01-14
@@ -156,7 +156,6 @@
pragma Pure (Case_Insensitive);
function "=" (Left, Right : String) return Boolean;
- function "/=" (Left, Right : String) return Boolean;
function ">" (Left, Right : String) return Boolean;
function ">=" (Left, Right : String) return Boolean;
function "<" (Left, Right : String) return Boolean;
@@ -838,7 +837,7 @@
using the generic formal equality operator for elements. Any exception
raised during evaluation of element equality is propagated.
-The function Length returns the number of key/element pairs in Container.
+The function Length returns the number of key/element pairs in Map.
The function Is_Empty is equivalent to Length (Map) = 0.
@@ -1057,7 +1056,7 @@
with procedure Process (Cursor : in Cursor_Type) is <>;
procedure Generic_Iteration (Map : in Map_Type);
-Generic_Cursor calls Process with a cursor that designates each
+Generic_Iteration calls Process with a cursor that designates each
node in the Map. Any exceptions raised during Process are propagated.
@@ -1085,9 +1084,9 @@
by a call on these routines should not increase significantly as the length of
the map increases.
-A.17.4 The Package Containers.Maps.Strings
+A.17.4 The Package Containers.String_Maps
-The package Containers.Maps.Strings provides private
+The package Containers.String_Maps provides private
types Map_Type and Cursor_Type, and a set of operations for each
type. It provides the same hashed map operations as the package
Containers.Maps does, with the difference that
@@ -1096,19 +1095,19 @@
Static Semantics
The declaration of the library package
-Containers.Maps.Strings has the same contents as Containers.Maps except:
+Containers.String_Maps has the same contents as Containers.Maps except:
* There is no generic formal Key_Type. Everywhere the formal type Key_Type
is specified, it is systematically replaced by type String.
* The Generic_Key function is omitted.
-A.17.5 The Package Containers.Maps.Wide_Strings
+A.17.5 The Package Containers.Wide_String_Maps
Static Semantics
The declaration of the library package
-Containers.Maps.Wide_Strings has the same contents as Containers.Maps.Strings
+Containers.Wide_String_Maps has the same contents as Containers.String_Maps
except that everywhere the formal type String is specified, it is
systematically replaced by type Wide_String.
@@ -2238,7 +2237,7 @@
and then the session object reacts to the I/O completion accordingly.
-A.17.4 The Package Containers.Maps.Strings
+A.17.4 The Package Containers.String_Maps
Hashed maps with type String as the key are nearly ubiquitous. The
canonical example is of course the word-frequency problem, in which
@@ -2251,7 +2250,7 @@
with Ada.Strings.Hash_String;
package Wordcount_Maps is
- new Ada.Containers.Maps.Strings
+ new Ada.Containers.String_Maps
(Element_Type => Natural,
Hash => Ada.Strings.Hash_String); -- case-sensitive
@@ -2410,7 +2409,7 @@
Our cache is just a map, indexed by file name:
package File_Cache_Types is
- new Ada.Containers.Maps.Strings
+ new Ada.Containers.String_Maps
(Element_Type => Context_Access,
Hash => Ada.Strings.Hash_String_Case_Insensitive,
Is_Equal_Key => Ada.Containers.Equal_String_Case_Insensitive);
@@ -2555,7 +2554,7 @@
as the key, and a Session_Access as the element, like this:
package Id_Maps is
- new Ada.Containers.Maps.Strings
+ new Ada.Containers.String_Maps
(Element_Type => Session_Access,
Hash => Ada.Strings.Hash_String); -- case-sensitive
@@ -3697,4 +3696,1439 @@
make it part of the interface. We therefore simplied the interface and the
description. (We consulted with the author of the proposal on this and other
changes.)
+
+****************************************************************
+
+From: Marius Amado Alves
+Sent: Wednesday, February 4, 2004 5:13 AM
+
+>Report of the ARG Select Committee on Containers
+>February 3, 2004
+>...
+
+Sorry for my poor knowledge of ARG procedure.
+Does this step mean the library is secured for Ada 2005?
+Thanks.
+
+****************************************************************
+
+From: Martin Dowie
+Sent: Wednesday, February 4, 2004 5:30 AM
+
+> Sorry for my poor knowledge of ARG procedure.
+> Does this step mean the library is secured for Ada 2005?
+> Thanks.
+
+Nope - it's still a "Work Item", see:
+
+http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AI-20302.TXT?rev=1.1
+
+
+
+Also, in the text of the AI :-
+
+with Ada.Containers;
+package Ada.Strings.Case_Insensitive is
+ pragma Pure (Case_Insensitive);
+
+ function "=" (Left, Right : String) return Boolean;
+ function "/=" (Left, Right : String) return Boolean;
+ ^^^^
+Guess this wasn't really meant.
+
+****************************************************************
+
+From: Martin Dowie
+Sent: Wednesday, February 4, 2004 8:11 AM
+
+1) Couple of typos in package Ada.Containers.Maps
+
+ generic
+ with procedure Process (Cursor : in Cursor_Type) is <>;
+ procedure Generic_Iteration (Map : in Map_Type);
+
+ - description refers to 'Generic_Cursor'
+
+ function Length (Map : Map_Type) return Natural;
+
+ - description refers to 'Container' when it should be 'Map'
+
+2) For routines like 'Generic_Iteration' shouldn't the 'Process'
+ generic subprogram parameter not have a 'Stop : out Boolean'
+ parameter? To allow early exit of the iteration, without
+ having to raise exceptions?
+
+****************************************************************
+
+From: Martin Dowie
+Sent: Wednesday, February 4, 2004 8:21 AM
+
+Is package Ada.Containers.Maps.Strings[ACMS] really what is
+intended, as Ada.Containers.Maps[ACM] is generic this means
+to use ACMS a user must first instantiate ACM and then
+instantiate ACMS.
+
+Charles didn't suffer from this problem as Unbounded maps (~ACM)
+and String Maps (~ACMS) were siblings not parent/child.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, February 4, 2004 8:57 AM
+
+>2) For routines like 'Generic_Iteration' shouldn't the 'Process'
+> generic subprogram parameter not have a 'Stop : out Boolean'
+> parameter? To allow early exit of the iteration, without
+> having to raise exceptions?
+
+Just use an active iterator.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, February 4, 2004 9:52 AM
+
+Note that that's not really the correct mode anyway: it should be inout,
+not just out, like this:
+
+ generic
+ with procedure Process
+ (Cursor : in Cursor_Type;
+ Done : in out Boolean) is <>;
+ procedure Generic_Iteration (Map : in out Map_Type);
+
+The problem with just out-mode is that you always have to give the
+parameter a value. But this is wrong, since you shouldn't be compelled
+to say anything if you merely want to continue. You should only have
+say something when you want to stop.
+
+If you only want to visit some of the items, then just use an active
+iterator, and exit the loop when you need to:
+
+ declare
+ I : Cursor_Type := First (M);
+ J : constant Cursor_Type := Back (M);
+ begin
+ while I /= J loop
+ declare
+ E : Element_Type := Element (I);
+ begin
+ --do something with E
+ exit when Predicate (E);
+ end;
+
+ Increment (I);
+ end loop;
+ end;
+
+****************************************************************
+
+From: Martin Dowie
+Sent: Wednesday, February 4, 2004 10:06 AM
+
+
+[snip]
+> If you only want to visit some of the items, then just use an active
+> iterator, and exit the loop when you need to:
+[snip]
+
+I could but wasn't part of the purpose of the library to allow us to
+do common things more easily? And I'd have to say I'd use a 'Quit'
+version a _lot_ more than the current process everything,
+every time one.
+
+I'd be delighted if both versions could be included! :-)
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, February 4, 2004 11:16 AM
+
+Dowie, Martin (UK) wrote:
+> I could but wasn't part of the purpose of the library to allow us to
+> do common things more easily? And I'd have to say I'd use a 'Quit'
+> version a _lot_ more than the current process everything,
+> every time one.
+
+It would be helpful if you could be specific about what kind of
+container you were using.
+
+The vector has neither active nor passive iterators, which means that
+for a vector you have to use a loop anyway.
+
+For the hashed map, I would find it very odd if you needed to traverse
+only some of its elements, since elements are stored in hash order.
+What would be the nature of the predicate?
+
+The sorted set is the borderline case.
+
****************************************************************
+
+From: Peter Hermann
+Sent: Wednesday, February 4, 2004 5:57 AM
+
+> package Ada.Strings.Case_Insensitive is
+
+indeed useful.
+expected to be overloaded for fixed and (un)bounded strings.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Wednesday, February 4, 2004 9:02 AM
+
+>Is package Ada.Containers.Maps.Strings[ACMS] really what is
+>intended, as Ada.Containers.Maps[ACM] is generic this means
+>to use ACMS a user must first instantiate ACM and then
+>instantiate ACMS.
+
+That's definitely a bug in the report. The string-key map is not a
+child of a generic. Maybe we should do this:
+
+package Ada.Containers.Maps
+package Ada.Containers.String_Maps
+
+****************************************************************
+
+From: Marius Amado Alves
+Sent: Wednesday, February 4, 2004 9:07 AM
+
+Yes, please change that. There is a steady requirement that a single
+instantiation must be enough to get a container.
+
+****************************************************************
+
+From: Pascal Obry
+Sent: Wednesday, February 4, 2004 10:10 AM
+
+> The problem with just out-mode is that you always have to give the
+> parameter a value. But this is wrong, since you shouldn't be compelled
+> to say anything if you merely want to continue. You should only have
+> say something when you want to stop.
+
+Agreed, this is the way iterators are designed in the POSIX 1003.5 standard
+for example.
+
+****************************************************************
+
+From: Marius Amado Alves
+Sent: Wednesday, February 4, 2004 9:02 AM
+
+> 2) For routines like 'Generic_Iteration' shouldn't the 'Process'
+> generic subprogram parameter not have a 'Stop : out Boolean'
+> parameter? To allow early exit of the iteration, without
+> having to raise exceptions?
+
+Indeed some people ban the use of exceptions for control flow. I guess they
+are not a majority in the committee. Fortunately ;-)
+
+/* However to take the exception route the exception should be defined.
+(Exit/Terminate_Immediately, _Now, _Prematurely?) Or a specification be made
+of what exceptions the iterator is guaranteed to propagate. Simply "all"
+would do. Maybe this is already there. I'm sorry, I didn't had time to read
+the AI fully yet. */
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 4, 2004 8:55 PM
+
+Marius Amado Alves wrote:
+
+> Sorry for my poor knowledge of ARG procedure.
+> Does this step mean the library is secured for Ada 2005?
+
+What it means is that the study committee has issued a report. No more, and
+no less. I would hope that we know more after the March ARG meeting, but
+there is no guarantee that we'll work on it (we never seem to get to
+everything on the agenda - we didn't work on AI-351, Time Ops in San Diego,
+for instance).
+
+Primarily, we just "cleaned up" Matt Heaney's proposal. We didn't change (as
+opposed to remove) functionality, with the exception of the Map container
+(where we reverted to a design more like the one Charles actually uses -
+with Matt's input). So the vast majority of design decisions are Matt's --
+we'd prefer to avoid design-by-committee.
+
+Martin Dowie wrote:
+
+> Is package Ada.Containers.Maps.Strings[ACMS] really what is
+> intended, as Ada.Containers.Maps[ACM] is generic this means
+> to use ACMS a user must first instantiate ACM and then
+> instantiate ACMS.
+
+Nope, that's clearly a bug. String_Maps ought to be usable by itself (it
+doesn't depend on the other package at all). (And this one is my fault, for
+not noticing the effect of the change.)
+
+And later, replying to Matt:
+
+>[snip]
+>> If you only want to visit some of the items, then just use an active
+>> iterator, and exit the loop when you need to:
+>[snip]
+
+>I could but wasn't part of the purpose of the library to allow us to
+>do common things more easily? And I'd have to say I'd use a 'Quit'
+>version a _lot_ more than the current process everything,
+>every time one.
+
+My understanding of Matt's design is that you use the passive iterator when
+you want to process everything (which is by far the most common), and you
+use an active iterator when you want to process part of the items. You might
+use an exception to terminate iteration in an error case, but not if you
+intended only to process part of the items. (Of course, there is no law
+requiring that, so YMMV!)
+
+I hadn't noticed that there is no passive iterator for vectors until Matt
+pointed it out last night (about 20 minutes before we released the report!).
+Consistency would suggest that there should be one, but note that it is
+easier to write an active iterator for a vector than it is to write a
+passive one:
+
+ for I in First(Vect) .. Last(Vect) loop
+ -- Do whatever.
+ end loop;
+
+versus
+
+ declare
+ procedure Process (I : in Index_Subtype) is
+ begin
+ -- Do whatever.
+ end Process;
+ procedure Do_It_All is new Generic_Iterator (Process);
+ begin
+ Do_It_All (Vect);
+ end;
+
+Besides being longer and harder to read, you have to know or look up the
+index subtype for the vector in order to write this. So we reached no
+conclusion about that in the 20 minutes we had to think about it.
+
+Marius Amado Alves wrote:
+
+> /* However to take the exception route the exception should be defined.
+> (Exit/Terminate_Immediately, _Now, _Prematurely?) Or a specification be
+made
+> of what exceptions the iterator is guaranteed to propagate. Simply "all"
+> would do. Maybe this is already there. I'm sorry, I didn't had time to
+read
+> the AI fully yet. */
+
+The wording for Generic_Iteration for a Map says:
+
+Generic_Iteration calls Process with a cursor that designates each
+node in the Map. Any exceptions raised during Process are propagated.
+
+So it's covered. This is important, because it means that the implementation
+must be able to clean itself up (if any is needed) when an exception
+propagates - it can't leave the Map in an unstable state.
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Wednesday, February 4, 2004 8:53 PM
+
+AI-302-03 asks
+
+> Anybody got better wording [for the quality of the String hashing
+> function]? Matt was nice enough to ignore these definitions
+> completely!
+
+See
+
+P. K. Pearson, "Fast Hashing of Variable-Length Text Strings," Comm.
+ACM, 1990 Jun
+
+It describes a "hashing function specifically tailored to
+variable-length text strings." It says that "similar strings are not
+likely to collide." (An implementation can be found in
+PragmARC.Hash_Fast_Variable_Length.) Perhaps you might think this last
+quote is "better wording".
+
+The actual algorithm produces 8-bit hash values, which may no longer be
+considered adequate, given
+
+> Hash_Type'Modulus shall be at least as large as the smaller of
+> System.Max_Binary_Modulus and 2**32.
+
+I have some comments on the proposal:
+
+The proposal has a structure called a "Vector" which is actually a list,
+which is a sequence that allows insertions and deletions at any point.
+"Vector" refers to a mathematical concept related to matrices to most
+software engineers. It may be that the STL refers to lists as vectors,
+but I hope we do not have to follow C++'s mistakes.
+
+Further, the proposal requires an inefficient array implementation, and
+several of the operations refer to this implementation. I think this is
+a mistake. Specify an general, unbounded list and let the implementor
+choose the implementation (which could be an array). As the proposal
+points out, correctly implementing a general list is not trivial, so it
+makes sense for a standard library to provide a list.
+
+Maps and sets also specify a specific implementation.
+
+If the intention is to have an extensible array structure, then I
+suggest that they be called Extensible_Arrays.
+
+Vector should have an iterator, in addition to allowing the user to
+explicitly iterate over the structure.
+
+> Open issue: This function returns a value that doesn't depend on it's
+> parameter. It possibility could be removed in favor of just saying
+> Index_Type'Pred(Index_Type'First) appropriately. Committee discussion
+> with the original proposal's author was inconclusive.
+
+I'd say that it should be a constant, not a function. The same seems to
+hold for First.
+
+Given that Back is defined as Index_Type'Succ (Last (Vector) ), and Last
+(Vector) could be Index_Type'Last, there seems to be a problem. There
+should be an assertion that Index_Type'Base'Last > Index_Type'Last.
+
+All the problems with Index_Type disappear with a general list, which
+would use a cursor.
+
+I would propose that the sort algorithm be made available to users for
+normal array types as well as for vectors. That would involve putting it
+in its own library unit and refering to that unit in Vectors.
+
+The Map structure is required to be implemented with a hash table. If
+we're going to have such a requirement, it should at least be named
+Hashed_Maps.
+
+An important thing about maps is that they provide fast searching,
+typically based on a lower-level structure such as a hash table or
+balanced tree. Such structures have uses of their own in addition to
+creating maps, and independent of the key/value concept of a map. For
+example, an application may collect a number of values and then need to
+quickly determine if a value is in that collection, and a searchable
+structure with a Get_First operation can be used for a priority queue.
+None of these applications use key/value pairs. Therefore, I think it's
+important to provide the underlying searchable structure to users.
+(Indeed, given the ease with which a user can wrap a key/value pair in a
+record, define comparison operations for that record that only use the
+key part, and create a map structure, given the existence of a
+searchable structure, it could be argued, since the proposal states that
+easily implemented structures should not be part of the library, that
+the library should only supply searchable structures, and not maps.)
+
+Do we really need Maps.[Wide_]Strings, given that an Unbounded_String
+can be used for the key type, and that this library should not be used
+for applications in which the use of Unbounded_Strings is not acceptable?
+
+The Sets package is mostly incomprehensible. Sets deal with elements,
+and operations must include testing if an element is in a set, creating
+a set from a list of elements (set "literals"), and set union,
+intersection, difference, and symmetric difference. Except for the
+membership test, these are missing from the package, so I don't see what
+it has to do with sets. It appears to be a searchable structure, not a
+set. This is corroborated by the package Generic_Keys, which allows the
+structure to be used as a map.
+
+The discussion of the package begins by talking about nodes, which is an
+undefined term. The reader has no idea what it has to do with the
+package, which is not specified in terms of nodes.
+
+"Sans" is a French word. Since the ARM is in English, we should use the
+English "without" instead. "No" might also be acceptable.
+
+I'd like to thank the select committee for their work. No library will
+completely please everyone. I will welcome any standard container
+library in Ada 0X.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, February 4, 2004 9:24 PM
+
+The term "vector" for extensible array is used in Java
+as well. I think we should strive to use terminology
+that has become widely used in the programming community.
+
+I personally consider an extensible array (i.e. a vector) a useful and
+important standard container. I don't feel the same way about a linked
+list, because it is so easy to implement what you want, and there
+are so many options when it comes to how to link the objects
+together that having a standard container for that hardly
+seems worthwhile (IMHO).
+
+So we settled on Vector, Map, and Set as three basic yet
+important abstractions that will help lift the level of
+programming above arrays and records. In my experience
+with using languages that have large container libraries,
+it is these three that are used more widely than all
+the others combined.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 4, 2004 9:29 PM
+
+I agree with one caveat: we're already adding something else called "Vector"
+to the standard (see AI-296), and two might just be too confusing.
+
+But, the container vector is more useful than the list container (because of
+the calculated O(1) access to elements). And they're too similar to support
+both when we're trying to support something managable.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, February 4, 2004 9:39 PM
+
+Jeffrey Carter said:
+...
+> Further, the proposal requires an inefficient array implementation, and
+> several of the operations refer to this implementation. I think this is
+> a mistake. Specify an general, unbounded list and let the implementor
+> choose the implementation (which could be an array). As the proposal
+> points out, correctly implementing a general list is not trivial, so it
+> makes sense for a standard library to provide a list.
+>
+> Maps and sets also specify a specific implementation.
+
+No, an implementation is suggested (in AARM notes), as are performance
+characteristics. That was one of the larger changes to Matt's original
+proposal. If we made that change incompletely somewhere, that needs to be
+fixed.
+
+That said, the most important thing is that all implementations have
+consistent performance characteristics (so that porting a program from GNAT
+to ObjectAda doesn't fail for performance reasons). If GNAT used an array
+implementation and ObjectAda used a list implementation for a Vector, access
+to elements (which would be O(N) on the imagined OA implementation) could be
+too slow for the port to be viable. That needs to be avoided. OTOH,
+specifying too much about the implementation would prevent using a better
+one -- in that case, we might as well just specify the source code of the
+entire library (including the bodies!), and we don't need all of this
+wording!
+
+> I would propose that the sort algorithm be made available to users for
+> normal array types as well as for vectors. That would involve putting it
+> in its own library unit and refering to that unit in Vectors.
+
+Bad idea. To do that, you'd need provide generic formal accessor functions;
+that would have a huge overhead of function calls for both Vectors and
+Arrays. On a code shared implementation like Janus/Ada, it probably would
+run ten times slower than the specified one.
+
+If we want an array sort, we should declare one:
+
+ generic
+ type Index_Type is (<>);
+ type Element_Type is private;
+ function "<" (Left, Right : Element_Type) return Boolean is <>;
+ type Array_Type is array (Index_Type) of Element_Type;
+ procedure Ada.Generic_Sort (Arr : in out Array_Type);
+
+(We'd need an unconstrained version, too.) But keep it separate from the
+Vector one (or any List one, for that matter).
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+I have hosted a reference implementation at my Earthlink home page:
+
+<http://home.earthlink.net/~matthewjheaney/charles/ai302-20040205.zip>
+
+For now it only includes the vector. There's a test_sort program in
+there too, so you have something you can run.
+
+I'll have the set and maps done in a few days.
+
+****************************************************************
+
+From: Robart A. Duff
+Sent: Thursday, February 5, 2004 10:13 AM
+
+Thanks, Matt!
+
+****************************************************************
+
+From: Jeffery Carter
+Sent: Thursday, February 5, 2004 10:58 AM
+
+Randy Brukardt wrote:
+
+> No, an implementation is suggested (in AARM notes), as are performance
+> characteristics. That was one of the larger changes to Matt's original
+> proposal. If we made that change incompletely somewhere, that needs to be
+> fixed.
+
+The normative text for vectors says
+
+"A vector container object manages an unconstrained internal array"
+
+That specifies an array implementation.
+
+> Bad idea. To do that, you'd need provide generic formal accessor functions;
+> that would have a huge overhead of function calls for both Vectors and
+> Arrays. On a code shared implementation like Janus/Ada, it probably would
+> run ten times slower than the specified one.
+
+Given that an array implementation is specified, there is no need for
+formal accessor functions. The vector can simply call an instantiation
+of the sort with the appropriate slice of its internal array. Since we
+require such an algorithm to exist, and it is useful to many users, it
+makes sense for it to be available outside the vector package.
+
+> If we want an array sort, we should declare one:
+>
+> generic
+> type Index_Type is (<>);
+> type Element_Type is private;
+> function "<" (Left, Right : Element_Type) return Boolean is <>;
+> type Array_Type is array (Index_Type) of Element_Type;
+> procedure Ada.Generic_Sort (Arr : in out Array_Type);
+>
+> (We'd need an unconstrained version, too.) But keep it separate from the
+> Vector one (or any List one, for that matter).
+
+If we only have one, I'd prefer it to be unconstrained. That allows
+operations such as the vector sort discussed above, where the size of
+the slice may change from call to call, without repeated instantiations.
+
+Sort for a list is a different creature. Merge sort is a good choice
+there, since a list already has the O(N) additional space that merge
+sort requires for array sorting (in the links), provided you have access
+to the list internals. Thus you get O(N log N) time in all cases and
+O(1) space.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 5, 2004 3:23 PM
+
+Jeff Carter wrote:
+
+> The normative text for vectors says
+>
+> "A vector container object manages an unconstrained internal array"
+>
+> That specifies an array implementation.
+
+Precisely my point. That is intended to say that there is a logical array in
+the container, but not necessarly an actual one. Matt's descriptions were
+too implementation-specific, and we moved most of that. But I'm not
+surprised that some was missed.
+
+...
+> Given that an array implementation is specified, there is no need for
+> formal accessor functions. The vector can simply call an instantiation
+> of the sort with the appropriate slice of its internal array. Since we
+> require such an algorithm to exist, and it is useful to many users, it
+> makes sense for it to be available outside the vector package.
+
+There is no intent that an array implementation is specified (it certainly
+won't be implemented that way on Janus/Ada); only that the performance
+characteristics are similar (or better) than that of an array
+implementation.
+
+In any case, I have no idea how an external generic would be able to mess
+around with the internal array - it certainly can't see it! You'd have to
+put the sort into the spec in order to do that -- and that's whats proposed
+and what you're objecting to.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 3:40 PM
+
+Randy Brukardt wrote:
+
+> Precisely my point. That is intended to say that there is a logical array in
+> the container, but not necessarly an actual one.
+
+Yes, exactly. This allows the implementor to leave the type system in
+order choose the optimal implementation for the vector container.
+
+An implementor can use any implementation that satisfies the property
+that insertion at the back end is (amortized) constant time, and the
+property that random access is constant time.
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Thursday, February 5, 2004 6:52 PM
+
+Randy Brukardt wrote:
+
+>>The normative text for vectors says
+>>
+>>"A vector container object manages an unconstrained internal array"
+>>
+>>That specifies an array implementation.
+>
+> Precisely my point. That is intended to say that there is a logical array in
+> the container, but not necessarly an actual one. Matt's descriptions were
+> too implementation-specific, and we moved most of that. But I'm not
+> surprised that some was missed.
+
+I read it as specifying an implementation. I suggest the wording be
+revised to make it clear that the discussion is of a logical array, not
+a requirement for an actual array.
+
+> In any case, I have no idea how an external generic would be able to mess
+> around with the internal array - it certainly can't see it! You'd have to
+> put the sort into the spec in order to do that -- and that's whats proposed
+> and what you're objecting to.
+
+I guess I wasn't clear. You would provide the external sort, and also
+specify the sort in the spec, with wording that the sort has the same
+characteristics as the external sort. This is based on the assumption
+that an array implementation is specified, so the sort algorithm, useful
+on arrays, must exist anyway.
+
+I'm reminded of my surprise that Ada-83 compilers had to support
+inifinte-precision arithmetic, but the language did not require that it
+made available to users. If the compiler writers have to implement the
+functionality, why not make it available to users? Case-insensitive
+string comparison is a similar thing: compilers have to recognize that
+frog, Frog, and FROG are the same identifier, but are (were) not
+required to make such comparisons available to users.
+
+****************************************************************
+
+From: Jeffrey Carter
+Sent: Thursday, February 5, 2004 11:38 AM
+
+Tucker Taft wrote:
+
+> The term "vector" for extensible array is used in Java
+> as well. I think we should strive to use terminology
+> that has become widely used in the programming community.
+
+I disagree, even though I know that's dangerous when discussing Ada with
+STT. An application that uses both extensible arrays and mathematical
+vectors will be very confusing if both are called vectors. Since an
+explicit design goal of Ada is to emphasize ease of reading, calling an
+extensible array a vector seems inappropriate.
+
+> I personally consider an extensible array (i.e. a vector) a useful and
+> important standard container. I don't feel the same way about a linked
+> list, because it is so easy to implement what you want, and there
+> are so many options when it comes to how to link the objects
+> together that having a standard container for that hardly
+> seems worthwhile (IMHO).
+
+I have no objections to an extensible array, provided it's clearly
+identified as such. I think it should look different from the proposal,
+but that's mainly a taste issue. I'd want direct analogs to indexing,
+both LHS and RHS (Put and Get?); slices, both LHS and RHS (Replace_Slice
+and Slice?); and 'First, 'Last, and 'Length (though 'First is a constant
+for an EA). An equivalent to 'range would be nice, but impossible. The
+only difference to a normal array would be that Put and Replace_Slice
+can accept indices not in First .. Last. I haven't given it a great deal
+of thought, so I'm sure I'm missing some subtleties, but I don't see a
+need for Front, Back, Insert, Delete, and so on.
+
+The proposal says that containers "that are relatively easy to code,
+redundant, or rarely used are omitted". It also says that lists are
+difficult to implement correctly. Given a list, structures such as
+deques, stacks, and especially queues are easy to implement. Since
+queues are common structures and not redundant (none of the proposed
+containers provides an efficient implementation of a queue), the
+proposal itself seems to argue that lists should be provided, since they
+are not easy to code correctly, and provide a basis for the user to
+easily code queues.
+
+> So we settled on Vector, Map, and Set as three basic yet
+> important abstractions that will help lift the level of
+> programming above arrays and records. In my experience
+> with using languages that have large container libraries,
+> it is these three that are used more widely than all
+> the others combined.
+
+There was an article by Mills [Harlan D. Mills, Richard C. Linger: Data
+Structured Programming: Program Design without Arrays and Pointers. IEEE
+Trans. Software Eng. 12(2): 192-197 (1986)] that proposed that
+applications only use queues, stacks, and sets (real sets, with union,
+intersection, and such operations). It's an interesting concept, and I
+agree with the aim of programs using appropriate abstractions and hiding
+lower level implementation details, especially use of pointers.
+
+****************************************************************
+
+From: Alexandre E. Kopilovitch
+Sent: Thursday, February 5, 2004 9:04 AM
+
+Tucker Taft wrote:
+
+> The term "vector" for extensible array is used in Java
+> as well. I think we should strive to use terminology
+> that has become widely used in the programming community.
+
+So call it Java_Vector - that will be at least consistent.
+
+Do you think that Java meaning for "vector" is more significant for Ada than
+mathematical meaning of this term (which never implied extensibility) ?
+
+Why not call that thing Flexible_Array (after Algol-68, I think) - this name
+will directly reflect the essense.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, February 5, 2004 1:37 PM
+
+Bill Wulf and other professors at CMU circa late 1970's were using the
+term "vector" to mean "array" (not necessarily extensible); that's the
+first time *I* heard it. So it's not a Java-ism.
+
+I think this meaning of "vector" derives from the maths meaning,
+even if it's not precisely the same thing.
+
+****************************************************************
+
+From: Stephen Leake
+Sent: Thursday, February 5, 2004 2:18 PM
+
+Jeffrey Carter <jrcarter@acm.org> writes:
+
+> Tucker Taft wrote:
+>
+> > The term "vector" for extensible array is used in Java
+> > as well. I think we should strive to use terminology
+> > that has become widely used in the programming community.
+>
+> I disagree, even though I know that's dangerous when discussing Ada
+> with STT. An application that uses both extensible arrays and
+> mathematical vectors will be very confusing if both are called
+> vectors. Since an explicit design goal of Ada is to emphasize ease of
+> reading, calling an extensible array a vector seems inappropriate.
+
+I agree with Tucker. I have code that uses both Cartesian vectors and
+extensible arrays. One is SAL.Math_Double.DOF_3.Cart_Vector_Type, the
+other is SAL.Poly.Unbounded_Arrays. Obviously, I have different names
+for them, as Carter wants. But if I called them
+SAL.Math_Double.DOF_3.Vector and SAL.Poly.Vector, I would have no
+chance of confusion. That's what package hierarchies are for.
+
+Since both Java and C++ use the term "vector" for an extensible array,
+I think Ada should also. Part of the point of the OY revision is to
+make the language more attractive to current users of other languages.
+This is an easy way to do that.
+
+> (Replace_Slice and Slice?); and 'First, 'Last, and 'Length (though
+> 'First is a constant for an EA).
+
+'First is not constant for SAL.Poly.Unbounded_Arrays; I provide both
+Append and Prepend operations. I don't think I've ever used Prepend,
+though; it was really just an exercise in what was possible.
+
+> .. I don't see
+> a need for Front, Back, Insert, Delete, and so on.
+
+I use Insert and Delete in real applications.
+
+> The proposal says that containers "that are relatively easy to code,
+> redundant, or rarely used are omitted". It also says that lists are
+> difficult to implement correctly. Given a list, structures such as
+> deques, stacks, and especially queues are easy to implement. Since
+> queues are common structures and not redundant (none of the proposed
+> containers provides an efficient implementation of a queue), the
+> proposal itself seems to argue that lists should be provided, since
+> they are not easy to code correctly, and provide a basis for the
+> user to easily code queues.
+
+I agree. A lists package would be nice.
+
+But I also agree with Tucker, that it is difficult to come up with one
+list package that really meets a wide range of needs.
+
+Perhaps one list package, that meets a narrow range of needs, would
+still be useful. It would set a style standard for other list packages.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 2:48 PM
+
+Alexandre E. Kopilovitch wrote:
+
+> So call it Java_Vector - that will be at least consistent.
+>
+> Do you think that Java meaning for "vector" is more significant for Ada than
+> mathematical meaning of this term (which never implied extensibility) ?
+>
+> Why not call that thing Flexible_Array (after Algol-68, I think) - this name
+> will directly reflect the essense.
+
+Tucker T. and Bob D. are both correct: the container is a "vector."
+
+Alexandre K. and Jeff C. are both incorrect. The container is not a
+list, not a Java_Vector, not an Extensible_Array, and not a Flexible_Array.
+
+It is a vector. It has the same semantics as the identically-named
+container in the STL. The one named "vector."
+
+The container whose name is vector does not have array semantics. There
+is no slicing for example.
+
+The container whose name is vector has the following important properties:
+
+o inserting at the back end is amortized constant time
+o supports random access of elements, in constant time
+
+Yes, internally a vector is implemented as an array. The Size function
+returns the length of this internal array, and Resize can be used to
+expand its length.
+
+But it is not an array. It is a container. Whose name is "vector".
+Just like the one in the STL.
+
+****************************************************************
+
+From: Alexandre E. Kopilovitch
+Sent: Thursday, February 5, 2004 3:46 PM
+
+No problem with all that if another term was chosen. Now, with "vector", this
+is name squatting (well, participation in name squatting in Ada case), which
+is fully appropriate for Java, somehow understandable for C++, but seems
+(still) inappropriate for Ada, especially taking into account that the involved
+term belongs to some Ada-friendly domain.
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Thursday, February 5, 2004 3:38 PM
+
+I wrote:
+
+> Bill Wulf and other professors at CMU circa late 1970's were using the
+> term "vector" to mean "array" (not necessarily extensible); that's the
+> first time *I* heard it. So it's not a Java-ism.
+
+Actually, the meaning was "one-dimensional array". But there was no
+implication that they could grow.
+
+> I think this meaning of "vector" derives from the maths meaning,
+> even if it's not precisely the same thing.
+
+I mean, what's a vector in 3-space? Basically, a one-dimensional array
+of 3 real numbers -- the X, Y, and Z coordinates.
+
+Matt wrote:
+
+> It is a vector. It has the same semantics as the identically-named
+> container in the STL. The one named "vector."
+
+This stuff comes from the C++ STL. I think gratuitous differences from
+that are unhelpful. (But I admit that I was one of the folks pushing
+for "cursor" instead of "iterator".)
+
+> The container whose name is vector does not have array semantics. There
+> is no slicing for example.
+
+Well, "no slicing" is hardly fundamental. It could be added, or
+programmed by the client.
+
+> The container whose name is vector has the following important properties:
+>
+> o inserting at the back end is amortized constant time
+> o supports random access of elements, in constant time
+
+I think "random access" is the essence of array semantics. After all,
+anything you can do with an array you can do with a linked list, and
+vice versa -- the only fundamental difference is the efficiency
+properties.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+Robert A Duff wrote:
+
+> This stuff comes from the C++ STL. I think gratuitous differences from
+> that are unhelpful. (But I admit that I was one of the folks pushing
+> for "cursor" instead of "iterator".)
+
+Yes. The world has settled on the name "vector." Let's use the terms
+everyone else is using, unless we have a good reason not to.
+
+(BTW, that's also why I used the name "Iterator_Type". But I have no
+issues with the name "Cursor_Type".)
+
+
+> I think "random access" is the essence of array semantics. After all,
+> anything you can do with an array you can do with a linked list, and
+> vice versa -- the only fundamental difference is the efficiency
+> properties.
+
+But that's the essence of the argument!
+
+Yes, it's *possible* to seek to specific elements in a linked list, but
+I would hardly call that "random access."
+
+If you need fast random access to the elements in a container, and the
+number of elements in the container is large, then you can effectively
+rule out using a linked list as the container.
+
+Of course you could make the argument the other way. If you need
+constant-time insertion of elements at any position, then that
+effectively rules out a vector, in favor of a list.
+
+****************************************************************
+
+From: Alexandre E. Kopilovitch
+Sent: Thursday, February 5, 2004 3:21 PM
+
+Robert A Duff wrote:
+
+> Bill Wulf and other professors at CMU circa late 1970's were using the
+> term "vector" to mean "array" (not necessarily extensible); that's the
+> first time *I* heard it.
+
+Yes, CMU always was (as far as I know) primarily engineering educational
+facility, and I know well that engineers (not software engineers, but rather
+general kind of engineers) often called "vector" any column or row of numbers.
+(not bothering themselves with the question how the components of that "vector"
+transform with a change of coordinate system). But apparently they never used
+this term for arrays of any other objects, and I almost never seen a case
+(even in engineering) where "vector" was used for extensible array - except
+Java and perhaps some C++ libraries.
+
+A notable exception is APL, in which "vector" is the basic term, and that
+"vector" is extensible. But in APL that "vector" is equipped with vast
+nomenclature of functions, many of them associated with genuine mathematical
+vectors, so the entire balance for the term was acceptable.
+
+> So it's not a Java-ism.
+
+Yes, not exactly - there were other precedents of sloppy usage of this term.
+But nevertheless a strong impression remains that it is exactly Java, which
+is a real reason, ground and reference for proposing this term for extensible
+arrays *now and for Ada0Y*.
+
+> I think this meaning of "vector" derives from the maths meaning,
+> even if it's not precisely the same thing.
+
+No, not at all - it lacks the primary mathematical meaning of it, and adds
+the primary feature, which meaning is totally non-mathematical (that is, there
+is no attempt to bring any mathematical meaning to it... and it will not be
+simple, if attempted).
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 5:11 PM
+
+
+
+Jeffrey Carter wrote:
+
+> The actual algorithm produces 8-bit hash values, which may no longer be
+> considered adequate, given
+>
+>> Hash_Type'Modulus shall be at least as large as the smaller of
+>> System.Max_Binary_Modulus and 2**32.
+
+In Charles I copied the hash function from GNAT. I figure if it's good
+enough for Robert Dewar it's good enough for me...
+
+
+
+> Vector should have an iterator, in addition to allowing the user to
+> explicitly iterate over the structure.
+
+No. Vector iterators are fragile, and hence very error prone.
+
+They are fragile because the (logical) internal array gets thrown away
+during expansion, which invalidates the iterator. It's too hard to keep
+track of whether a vector iterator is still valid, and most of the time
+you end up with a dangling reference.
+
+The STL has vector iterators in order to provide the infrastructure
+necessary to support generic algorithms.
+
+In Ada they are not necessary, because you can use locally-declared
+subprograms to fit within such a framework.
+
+
+
+
+>> Open issue: This function returns a value that doesn't depend on it's
+>> parameter. It possibility could be removed in favor of just saying
+>> Index_Type'Pred(Index_Type'First) appropriately. Committee discussion
+>> with the original proposal's author was inconclusive.
+>
+>
+> I'd say that it should be a constant, not a function. The same seems to
+> hold for First.
+
+Front can probably go away. First is there for consistency with other
+containers.
+
+
+
+> Given that Back is defined as Index_Type'Succ (Last (Vector) ), and Last
+> (Vector) could be Index_Type'Last, there seems to be a problem. There
+> should be an assertion that Index_Type'Base'Last > Index_Type'Last.
+
+That's not really possible for generic actual index types such as
+Natural or Positive.
+
+We could get rid of the assertion, but this would impact implementors.
+That's why it's still an open issue.
+
+In my reference implementation, I don't think the generic actual type
+has to have IT'Base'First < IT'First, since internally I use Integer
+subtypes for everything.
+
+http://home.earthlink.net/~matthewjheaney/charles/ai302-20040205.zip
+
+
+
+> All the problems with Index_Type disappear with a general list, which
+> would use a cursor.
+
+The original proposal included list containers, but they were not
+included in the subcommittee report, in order to keep the size of the
+report more manageable.
+
+
+
+> An important thing about maps is that they provide fast searching,
+> typically based on a lower-level structure such as a hash table or
+> balanced tree.
+
+My original proposal had both sorted and hashed maps, but in order to
+keep the subcommittee report small support for sorted maps was removed.
+
+
+> Such structures have uses of their own in addition to
+> creating maps, and independent of the key/value concept of a map. For
+> example, an application may collect a number of values and then need to
+> quickly determine if a value is in that collection, and a searchable
+ > structure with a Get_First operation can be used for a priority queue.
+
+That's what the sorted set is for.
+
+
+> None of these applications use key/value pairs.
+
+So use the sorted set.
+
+
+> Therefore, I think it's
+> important to provide the underlying searchable structure to users.
+
+Just use the sorted set container. If guarantees that searches only
+take O (log N) even in the worst case.
+
+
+> (Indeed, given the ease with which a user can wrap a key/value pair in a
+> record, define comparison operations for that record that only use the
+> key part, and create a map structure, given the existence of a
+> searchable structure, it could be argued, since the proposal states that
+> easily implemented structures should not be part of the library, that
+> the library should only supply searchable structures, and not maps.)
+
+The (hashed) map stores the key and element as separate components of
+the internal node of storage.
+
+If you have a record like that, containing a key-part component, then
+use the sorted set, and instantiate the nested generic package Generic_Keys.
+
+
+> Do we really need Maps.[Wide_]Strings, given that an Unbounded_String
+> can be used for the key type, and that this library should not be used
+> for applications in which the use of Unbounded_Strings is not acceptable?
+
+Yes, we really need string-key maps.
+
+
+> The Sets package is mostly incomprehensible. Sets deal with elements,
+> and operations must include testing if an element is in a set, creating
+> a set from a list of elements (set "literals"), and set union,
+> intersection, difference, and symmetric difference. Except for the
+> membership test, these are missing from the package, so I don't see what
+> it has to do with sets. It appears to be a searchable structure, not a
+> set. This is corroborated by the package Generic_Keys, which allows the
+> structure to be used as a map.
+
+A "set" is really any sorted sequence of items. If you want set
+intersection, symmetric difference, etc, then just use a generic
+algorithm. See the Charles library for such algorithms.
+
+Of course, if you want target of a set union operation to be the set
+itself, then just use Insert to insert the items.
+
+The subcommittee report has several examples of how sets are used, and
+there's at least one example showing how to use the nested generic package.
+
+See the last two slides in my AE-2003 paper presentation for an example
+of how to take the union of a set and a (sorted) list:
+
+http://home.earthlink.net/~matthewjheaney/charles/charlesppt.htm
+
+My original proposal has the same example at the very end:
+
+http://home.earthlink.net/~matthewjheaney/charles/ai302.txt
+
+
+
+> "Sans" is a French word. Since the ARM is in English, we should use the
+> English "without" instead. "No" might also be acceptable.
+
+Je crois que non. C'est une bonne idea.
+
+The name for Delete_Sans_Increment comes from Emacs lisp, which has the
+functions file-name-sans-extension and file-name-sans-versions.
+
+It was also in homage to Ada's French history, given that her original
+designer was French, and worked for a French company.
+
+Why do you think "rendevous" was named that way?
+
+
+
+> I'd like to thank the select committee for their work. No library will
+> completely please everyone. I will welcome any standard container
+> library in Ada 0X.
+
+If you don't immediately grok how vectors and sets and maps work, then I
+suggest familiarizing yourself with the STL. There are lots of tutorials
+on the WWW.
+
+I also recommend Stanley Lippman's little book Essential C++. That was
+my introduction to the STL, and what originally convinced me that
+Stepanov's approach was the correct one.
+
+You might also like Accelerated C++ by Andrew Koenig and Barbara Moo,
+which uses the STL as a basis for teaching C++.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 5, 2004 5:49 PM
+
+Matt's too modest. The tutorial that makes up the !example section is
+actually quite good. I learned a lot about how the packages work (and how to
+use them) from reading it carefully, and I recommend that everyone do that
+to better understand Matt's work.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 5, 2004 3:48 PM
+
+Jeffrey Carter wrote:
+
+...
+> > I personally consider an extensible array (i.e. a vector) a useful and
+> > important standard container. I don't feel the same way about a linked
+> > list, because it is so easy to implement what you want, and there
+> > are so many options when it comes to how to link the objects
+> > together that having a standard container for that hardly
+> > seems worthwhile (IMHO).
+>
+> I have no objections to an extensible array, provided it's clearly
+> identified as such. I think it should look different from the proposal,
+> but that's mainly a taste issue. I'd want direct analogs to indexing,
+> both LHS and RHS (Put and Get?); slices, both LHS and RHS (Replace_Slice
+> and Slice?); and 'First, 'Last, and 'Length (though 'First is a constant
+> for an EA). An equivalent to 'range would be nice, but impossible. The
+> only difference to a normal array would be that Put and Replace_Slice
+> can accept indices not in First .. Last. I haven't given it a great deal
+> of thought, so I'm sure I'm missing some subtleties, but I don't see a
+> need for Front, Back, Insert, Delete, and so on.
+
+Let's see:
+- direct analogs to indexing, both LHS and RHS (Element, Replace_Element);
+- slices (nope);
+- 'First (First), 'Last (Last), 'Length (Length);
+
+Looks like pretty much everything is in there. And slicing will be expensive
+if the implementation is not a straight array, so it's somewhat dubious.
+Insert and Delete provide easier ways of adding or removing items than
+slices - and how often do you use a slice of a non-string type for something
+other than inserting or deleting elements anyway??
+
+Ada doesn't (and isn't) going to support user-defined indexing or
+user-defined attributes, so this is about the best you can do. So what's the
+complaint (other than the name)??
+
+> The proposal says that containers "that are relatively easy to code,
+> redundant, or rarely used are omitted". It also says that lists are
+> difficult to implement correctly.
+
+I think that's a mistake; only very rare operations are difficult to code.
+We didn't update every piece of the original text, and that one is
+misleading.
+
+> Given a list, structures such as
+> deques, stacks, and especially queues are easy to implement. Since
+> queues are common structures and not redundant (none of the proposed
+> containers provides an efficient implementation of a queue), the
+> proposal itself seems to argue that lists should be provided, since they
+> are not easy to code correctly, and provide a basis for the user to
+> easily code queues.
+
+The user can easily code a queue in terms of a Vector (that's one of the
+uses of Insert!). We dropped the list component because it had an identical
+interface to the Vector component, but was less flexible (no computed O(1)
+access).
+
+In any case efficiency is not a goal of the standard containers. It would be
+incorrect for the standard to specify performance to the point that only a
+single implementation would be possible. Moreover, we anticipate a secondary
+standard that *does* try to provide more control over performance (by adding
+lists, bounded forms, etc.)
+
+In my view, it is a mistake for projects to depend on standard containers
+where there are critical performance requirements (not just time, but also
+space as well). In that case, you really have to have control of the
+implementation -- you really need *all* of the source code. You can't trust
+something provided by the standard (or your compiler vendor) in those cases.
+
+In any case, the purpose of these containers is to provide a seed and a
+standard direction. I would hope that they would reduce the tower of babel
+that Ada containers are nowdays - by providing a style for other containers
+to follow. No one is suggesting that these are sufficient to solve all
+programming problems - just 80% of them, especially in prototypes and in Q&D
+programs.
+
+****************************************************************
+
+From: Martin Dowie
+Sent: Thursday, February 5, 2004 5:50 PM
+
+> Dowie, Martin (UK) wrote:
+> > I could but wasn't part of the purpose of the library to allow us to
+> > do common things more easily? And I'd have to say I'd use a 'Quit'
+> > version a _lot_ more than the current process everything,
+> > every time one.
+>
+> It would be helpful if you could be specific about what kind of
+> container you were using.
+
+I was thinking, primarily, of a project that used single (bounded) lists to
+hold commands (a basic, domain-specific, scripting language I guess),
+one of which was 'stop this sequence of commands'.
+
+This pattern has since shown itself to be quite common in embedded
+systems - for either domain-specific scripting languages or graphics.
+
+There is the other idiom where one is processing an iteration of items
+and an external event occurs that stops the processing - e.g. the 'stop'
+button is pushed on a GUI-search window, but it could equally be a
+50Hz message over a 1553.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, February 5, 2004 6:14 PM
+
+> I was thinking, primarily, of a project that used single (bounded) lists to
+> hold commands (a basic, domain-specific, scripting language I guess),
+> one of which was 'stop this sequence of commands'.
+
+My understanding of the model is that passive iterators are only for cases
+where you want to iterate over the entire container. Thus, this is clearly a
+use for an active iterator. Indeed, given the iteration model of packages,
+there's hardly any reason to use a passive iterator. They're harder to write
+(a subprogram and instantiation are required), and (especially if a Quit
+parameter is provided), harder to understand.
+
+We dropped the passive iterator from the Ada.Directories package precisely
+because even ARG members were confused about how it worked. Even though it
+was a classic passive iterator with a Quit parameter. Perhaps the confusion
+really was the Quit parameter (I thought it was the whole idea), but in any
+case, you've got to keep them simple.
+
+> This pattern has since shown itself to be quite common in embedded
+> systems - for either domain-specific scripting languages or graphics.
+>
+> There is the other idiom where one is processing an iteration of items
+> and an external event occurs that stops the processing - e.g. the 'stop'
+> button is pushed on a GUI-search window, but it could equally be a
+> 50Hz message over a 1553.
+
+It seems to me that an abort situation is best handled by propagating an
+exception. Otherwise, you end up distributing termination code/flags
+everywhere in the application. But YMMV.
+
+****************************************************************
+
+From: Jeffery Carter
+Sent: Thursday, February 5, 2004 6:39 PM
+
+Matthew Heaney wrote:
+
+> Alexandre K. and Jeff C. are both incorrect. The container is not a
+> list, not a Java_Vector, not an Extensible_Array, and not a
+> Flexible_Array.
+
+Matthew H. is incorrect. The data structure is not a vector.
+
+I am at least as qualified as Matthew H. to make such pronouncements.
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
+From: Matthew Heaney
+Sent: Thursday, February 5, 2004 9:31 AM
+
+****************************************************************
+
Questions? Ask the ACAA Technical Agent