Re: List Container Straw Man

[Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>]

"Nick Roberts" <nickroberts@adaos.worldonline.co.uk> writes:

> Please make the type List derived from an abstract 'iterator' type. List
> would then inherit the iteration operations of this type. An alternative is
> for List to provide a function that generates or gives access to an object
> derived from this iterator type.
> 
> For example:
> 
> 
> generic
>    type Element_Type is private;
> 
> package Containers is
> 
>    ...
> 
>    type Terminating_Producer is abstract tagged limited private;
> 
>    procedure Read (Producer: in out Terminating_Producer; Item: out
> Element_Type) is abstract;
> 
>    function End_of_Data (Producer: in Terminating_Producer) return Boolean
> is abstract;
> 
>    ...
> 
>    type Sequence_Reproducer is abstract new Terminating_Producer with
> private;
> 
>    procedure Restart (Reproducer: in out Sequence_Reproducer) is abstract;
> 
>    type Sequence_Recorder is abstract new Sequence_Reproducer with private;
> 
>    procedure Rewrite (Reproducer: in out Sequence_Reproducer) is abstract;
> 
>    procedure Write (Recorder: in out Sequence_Recorder; Item: in
> Element_Type) is abstract;
> 
>    function Count (Recorder: in Sequence_Recorder) return Natural is
> abstract;
> 
>    function Is_Recording (Recorder: in Sequence_Recorder) return Boolean is
> abstract;
> 
>    ...
> 
> end Containers;
> 
> 
> The Restart procedure tells a sequence reproducer to start producing its
> data over again. The Rewrite procedure tells a sequence recorder to start
> recording data (at which point Write can be used and Read cannot;
> Is_Recording returns True). Restart than tells it to start reading again (at
> which point Write cannot be used; Is_Recording returns False). Count returns
> the number of items currently recorded.

Well, I find this very confusing; there is not enough documentation
for me.

First, you switched from "Sequence_Reproducer" to "Sequence_Recorder".
Or maybe you left out a type?

Why are there three (or four) independent types? How do I write to a
producer object in the first place, so there is something to read?
Conversely, how do I read from a recorder?

> package Containers.Lists.Unbounded is
> 
>    type Linked_List is new Sequence_Recorder with private;
> 
>    -- Representing a singly-linked (forward) list type, with typical
> operations.
> 
>    function "&" (Left, Right: in Linked_List) return Linked_List is
> abstract;

Why is this abstract? How many implementations of a singly-linked list
are there? Hmm, I guess we have discussed several here, including
various options for making Iterators safe. So maybe this makes sense.

>    ...
> <snip> 
> end Containers.Utility.Lists;
> 
> 
> In this way, a piece of software which only needs to iterate over a
> container can be passed any of the list types, or other container types.

This is true. But it leads to the "complex instantiation" problem that
is one requirement for the list package under discussion.

It also introduces tagged types, which some users might want to avoid
(they can have run-time overhead, or be hard to test).

Personally, I've never run across a situation where this abstract
container design really made sense; it was always more important to
optimize the implentation for real-time issues (I'm a rocket
scientist, after all :).

In a truly complete library, I think both options should be available;
abstract containers and concrete, simple lists. Perhaps the "Dennison
List" package could be used to implement the doubly-linked list
variant of the abstract container package; would that work for you?

> Please don't get this elementary aspect of the design wrong!

"Wrong" is too strong. Just because some people give different design
options different importance does not make them wrong!

-- 
-- Stephe