Re: why not

["Matthew Heaney" <mheaney@on2.com>]

"Marin David Condic" <dont.bother.mcondic.auntie.spam@[acm.org> wrote in
message news:9rp9bk$6m9$1@nh.pace.co.uk...
> Perhaps you would agree with my proposal that a first cut at a standard
> component library could start with some basic form of Lists and Maps?

We could start with an unbounded, doubly-linked list, a la STL std::list.

>  I'd
> like to see an informal adoption of a handful of packages that let the
user
> make lists (sorted? unsorted?) of basic data types (things like Integers,
> Strings, plain vanilla records, ...) and Maps of similar items.

The element type that is nonlimited and definite.  (Type String all by
itself would NOT be supported, because that type is unconstrained.)

The container itself doesn't do sorting.  (I assume there would be a
separate algorithms package, that operates on iterators.  That influences
what iterator types look like.)

Here's one idea:

generic
   type Element_Type is private;
   with function "=" (L, R : Element_Type) return Boolean is <>;
package Ada.Lists_Unbounded is

   type List_Type is private;

   procedure Push_Front (List : in out List_Type; Element : in
Element_Type);

   procedure Push_Back (List : in out List_Type; Element : in Element_Type);

   procedure Clear (List : in out List_Type);
...
   type Iterator_Type (List : access List_Type) is limited private;

   type Constant_Iterator_Type (List : access constant List_Type) is limited
private;

   type Reverse_Iterator_Type (List : access List_Type) is limited private;

   type Constant_Reverse_Iterator_Type (List : access constant List_Type) is
limited private;
...
end;

You have to decide whether the List_Type is limited or nonlimited.  The
latter implies that List_Type must privately derives from Controlled.

You have to decide whether the List_Type will automatically Clear itself
when its lifetime ends.  Your answer would influence whether List_Type is
Controlled.

The decision to be Controlled influences where the generic may be
instantiated (say, only a library scope).

Note that not automatically reclaiming memory by the list itself isn't such
a bad thing, because you can include another component in the library to do
this, like this:

generic
   type Container_Type (<>) is limited private;
   with procedure Clear (Container : in out Container_Type) is <>;
package Container_Control is

   type Control_Type (Container : access Container_Type) is limited private;
...
end;

declare
   List : aliased List_Type;
   Control : Control_Type (List'Access);
begin
   ... use list
end;

When the scope ends, Control is finalized, and during its Finalization it
calls Clear (Container).

Not making the container types controlled will make them more efficient, but
introduce the possibility for memory leaks (if the client doesn't also use a
helper type, as above).

Of course the containers should NOT be task safe.  Threading behavior can be
handled by the client himself, by combining a sequential container type with
other language primitives.  This is consistent with how the rest of the
predefined library has been designed.