Re: List Container Straw Man

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

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

> "Stephen Leake" <stephen.a.leake.1@gsfc.nasa.gov> wrote in message
> news:u1yjacqea.fsf@gsfc.nasa.gov...
> > 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?
> 
> I made a mistake: in the Print_a_List procedure declaration, I used the type
> Sequence_Producer when I should have used Terminating_Producer. Sorry.

Well, ok. But that doesn't respond to my point.

> > Why are there three (or four) independent types?
> 
> Each adds one extra level of functionality. This is vitally important.

They are not "levels"; they are independent! They could easily be in
separate packages, and have nothing to do with each other. At least,
that's what the package you presented says.

> > 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?
> 
> Remember, an abstract type promises certain operations (and assumed
> characteristics). The concrete types derived from it must fulfil those
> promised operations (and should fulfil the characteristics), but nothing
> stops them adding more operations (and characteristics) of their own!

Ok, but once again, you miss my point. The package you presented does
not allow writing to a producer. How is that useful? If _every_
derived type must add a "write" operation, it's a bad design.

> For example, a list type might be derived from Sequence_Recorder, so
> that its contents can be read using Read and End_of_Data, and then

No, there is no "read" operation for Sequence_Recorder in your proposal.

> re-read using Restart, and then rewritten using Rewrite and Write.
> These are the promised operations that the list type must fulfil,
> but it could add many others (insertion, deletion, whatever).
> 
> Take another example, a random number generator (RNG). An RNG type might be
> derived from Sequence_Producer (the most primitive, non-terminating type).
> This means you can read from it using Read, but there is no end to the data
> (and no End_of_Data function). 'Read' is the sole promised operation. The
> RNG type would doubtless add at least one other operation to allow seeding
> of itself.

Well, that makes sense. But we are supposed to be discussing linked
lists, not RNG.

> This is why it is vital to have many types, each adding a small set
> of extra 'promised' operations.

The operations of these four types do _not_ "add" to each other; they
are totally independent.

> And because objects (values) of both the list type, the RNG type (or
> indeed any other container type conforming to the design) can be
> passed straight into any unit which takes one of the abstract
> iterator types as a parameter, it means you get the 'write once, use
> anywhere' effect of good software engineering.

Um, I would rather _not_ have to write a procedure that is expecting a
linked list, but must be prepared to deal with an RNG! There may be
some procedures for which this is appropriate (I'd _really_ like to
see an example), but it is not typical.

"Write once, use anywhere" refers to porting applications across
operating systems and CPUs, not to porting procedures across data types.

> > > 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.
> 
> Please see my reply to Marin in this thread. I hope it shows that the
> instantiations you need (two) are not really all that onerous.

Well, my library (http://users.erols.com/leakstan/Stephe/Ada/sal.html)
requires three or four instantiations to get a list, and I don't find
that 'onerous'. But others do, particularly students. So I think it is
worth making the attempt to come up with a useful list package that
only requires one instantiation.

> > It also introduces tagged types, which some users might want to
> > avoid (they can have run-time overhead, or be hard to test).
> 
> I don't think that's true in the great majority of cases. 

Well, you are entitled to your opinion, as I am to mine. But until
someone comes up with hard survey data, this point cannot be ignored.

> Ada can implement tagged types very efficiently (because it does not
> have to deal with multiple inheritance). I suppose hard data on this
> will be hard to get.

Yes.

> > 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 :).
> 
> I use this scheme all the time. I don't think it's unsuitable for most
> real-time software. 

Um, it is not wise to challenge a rocket scientist on this point! How
many satellites have you launched recently? When was the last time you
had to write code that met a 0.01 millisecond time stamp accuracy
requirement, and did it continuously for a week straight? There is no
place for abstract containers in this code; I need to control
_everything_! 

> Many actual container types will be (but that's a different matter).
> 
> > 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?
> 
> For the sake of saving one instantiation? Maybe, but I doubt it.

No, for the sake of allowing applications that don't need the abstract
container type to still get a standard list package, while also
providing a standard abstract container type.

> > > 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!
> 
> You're right, of course, but I get a little frustrated at times, Stephe!

Ok. Apology accepted.

To relieve my frustration, please post a compilable example of your
design, that instantiates a linked list package, declares an object of
the list type (named "List_Type" :), writes a sequence of integers
into it, and the reads the sequence back out. That will make many
things about your design much clearer.

-- 
-- Stephe