Re: List Strawman JC01

[Ted Dennison<dennison@telepath.com>]

In article <3C0EB851.77E7172A@boeing.com>, Jeffrey Carter says...
>
>Ted Dennison wrote:
>> be better to put this information in a matrix in the parent pacakge so that
>Except we're talking about one package for unbounded lists. In the case
>of this strawman, there's no parent package.

Not true. Since the name is "Containers.Lists.Unbounded", there are actually
*two* parent packages. I'm compiling the strawman before I post it, so those
packages do exist. Its just that there isn't anything in them to look at yet, so
I haven't bothered to post them. :-)

How about I add a 1-row "matrix" to the top of the package for now, with a note
that it will get moved to the parent when there are more rows?

>that, we can decide what notation to adopt. If we want a bounded list
>package at some point with similar semantics, we probably will need list
>parameters.

That may be an issue, but it doesn't have to be done that way. We could decide
to still keep a pointer to the list in the iterator, which would allow the same
iterface as the current Unbounded strawman. But that's a discussion for another
time.

>> >   Storage_Exhausted : exception;
>> 
>> Why is this considered superior to STORAGE_ERROR? Do you have plans to do
>> something here other than just handle STORAGE_ERROR and raise Storage_Exhausted?
>
>As a general principle, a package should not be propagating predefined
>exceptions to its clients. Also, this helps allow differing

By "predefined" I take it you mean "declared in the standard Ada libarary
somewhere". Considering that the ultimate goal of this facility is to be part of
the standard Ada library, I don't think your principle applies here. :-)

Personally I don't really subscribe to that principle anyway. You should
certianly change the exception if the one raised isn't at the appropriate level
of abstraction for the user. This will, in practice, amount to the same
principle as yours. For instance, I wouldn't allow Ada.IO_Exceptions.Name_Error
to be propagated out of a log file facility. I'd change it to something like
Logfile.Unavailable or Logfile.Installation_Error, because those better describe
the condition causing the problem. Also, the fact that Ada's IO facilities are
used (rather than system calls or something) is an implementation detail that
the user doesn't care about. By this same principle you clearly wouldn't want to
allow Contraint_Error due to in internal calculation out of your routine either.
But this is quite different. Dynamic allocation is clearly going on here, and
Ada.Storage_Error perfectly describes the problem (as evidenced by the fact that
your name for it is hardly different at all).

>This is much less clear than "<". Everyone knows what "<" does.
>"Swap_Items (L, R ...) return Boolean;" is meaningless.

In the context of a boolean expression, yes everyone knows. In the context of
the internals of a sort routine, its completely undefined. Is the "Left"
parameter the "Front" side or the "Back" side? Does a "True" result mean its out
of order or in order? You can supply answers to these questions I'm sure, but
the answers will be fairly arbitrary. They are certianly not self-evident.

>Is the array
>
>(1, 2, 3, 4)
>
>in ascending order? The answer is obvious to most people, because an
>array is a sequence.

No, its obvious to most people because the array is indexed by a discrete type,
upon which the "<" operator is defined. Thus the convention that ascending order
is the order in which items whose indexes return True for ">" will also have
values return true for ">" can be applied.

We have no such relationship for our doubly-linked list. "<" is not defined on
iterators. "Next" requires a direction parameter to disambiguate. The only
ordering a doubly-linked list has is the one the user puts upon it. I could look
at the list left to right, right to left, top to bottom, bottom to top, and no
one can say my view is wrong. I can iterate from front to back or back to front
and it won't make any real difference.

The only directional terminology we have at all is "Front" and "Back". For
anything directional to make sense at all, it *must* be cast in those terms. "<"
is not cast in those terms.

>the First element, the Next element, the Next element, ... , the Last
..
>First and Second are perfectly well defined for a list. The first
>element in List is designated by First (List); the second by Next (First

You are probably thinking of a singly-linked list. That makes a bit of sense for
a singly-linked list because there is only one way you can iterate. Therefore we
know what ascending order is, because there's only one direction to traverse the
list. For a doubly-linked list, either end is equal. There may be an ordering,
but the direction of it is entirely imposed by the user. I'll ask you to go look
at the spec again. There is no "First" function, only a "Side" function, which
takes a directional parameter to disambiguate. "Next" also requires a
directional parameter to disambigute.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.