Re: List Container Strawman 1.4

[Ted Dennison<dennison@telepath.com>]

In article <9ve8jn$esilp$1@ID-25716.news.dfncis.de>, Nick Roberts says...
>
>"Ted Dennison" <dennison@telepath.com> wrote in message
>news:z9aN7.41127$xS6.69040@www.newsranger.com...
>
>> "unbounded" package, I don't think the user should have to worry about
>running
>> out of resources like iterators. That sort of breaks the whole "unbounded"
>> philosophy.
>
>I've fixed that. For unbounded lists, the user can have up to 255 cursors
>(iterators), dynamically allocated, which can be dynamically varied. The
>limit of 255 is arbitrary, and could be increased if you think it necessary.

I don't think that really addresses the concern, which is that this isn't really
an "unbounded" approach. Not that I'm a huge fan of the approach the current
strawman uses either. If you've been reading a while, you know I'd lean towards
making the users responsible for iterator safety. But the current approach is
the only one that we have been able to get general agreement on. If you could
convince folks that your (hugely) bounded approach was the way to go, I'd
certianly put that in instead. But so far I see absolutely no sign of that
happening. Not a single other person has come out in support of it in two weeks,
and I see no evidence that this situation would change if we were to delay
things another two weeks.


>The fact that an array version is included for each operation that has a
>secondary data parameter is not just nice, it is necessary for the sake of
>efficiency. Consider the extra work done by converting the array to a list,
>and then applying that list.

That's only an issue if you don't have the Strawman's "Splice" routine.

>I'm afraid I've got quite a few comments on your straw man as it is
>currently. Here goes.
>
>[1] I would prefer the name 'Element_Type' to 'Element' for the generic
>parameter, since 'Element_Type' is what Ada.Sequential_IO and Ada.Direct_IO
>use.

My opinion on the stupidity of "_Type" is probably well known by now. If we were
trying to emulate either of those packages in other ways, or there was a good
case for it possibly causing confusion, then it might be worth using "_Type"
regardless. But I don't believe either is the case here.

>[2] I would prefer a name other than 'List' for the list type, since 'List'
>seems to be such a natural name for parameters and objects of a list type

That issue (type vs. object naming guidelines) has been thouroughly discussed
already a week and a half ago. General names like "List" are for types, while
objects (and parameters) should be named something more specific that designates
either exactly what the object is, or what its role in the system is (eg:
"Target"). This isn't just some rule I made up. The Ada Quality and Style guide
phrases it this way:

* Use singular, general nouns as subtype identifiers. (3.2.2 - Subtype Names)
* Choose identifiers that describe the object's value during execution. (3.2.3 -
Object Names)

You seem to worry that this will cause problems, but we already have a package
spec and it hasn't caused problems that I can see. I'm thinking we can get by
just fine in the body too. Those are the only places it should be an issue, as
everywhere else dot notation can be used to disambiguate.  

>(not necessarily in the list package spec, but elsewhere). If the unbounded
>list package is going to be named 'x.Lists.Unbounded', it would seem natural
>to use the name 'Unbounded_List' (by analogy to
>Ada.Strings.Unbounded.Unbounded_List). I do feel that the need for
>consistency outweighs any complaint of wordiness.

If folks *really* want that, we can do it. But the current difference is quite
conscious. All things being equal, I'm in favor of keeping things consistent as
well. But in this case, all things aren't even close to equal. That naming
system (repeating the package name in the type name) was a tragic mistake, and I
for one am not in favor of spreading the cancer further throughout the standard
libraries in the name of consistency. 

>[3] Why is Element_Array declared with a Natural index subtype? Wouldn't
>Positive be more appropriate?

An oversight. You are quite correct. I'll fix it.

>[4] If you consider their usage, the functions 'To' and 'From' are surely
>confusingly named. What is wrong with 'To_List' and 'To_Array' (or similar)?

That may be a bit of an issue. I general I think things should be named relative
to the package name. If one uses full dot notation, things look great this way.
However, in this case it might be a bit obscure without it:

Foo_List := To (Foo_Items);

and

Foo_Items := From (Foo_List)

The flip answer to this it to use the package names anyway if it doesn't look
clear without them. However, it would perhaps be nice if things aren't quite so
obtuse without them.

>[5] Analogous to the Ada.Strings.Maps.To_Set function, the function
>'Singleton' should be named more like 'To_List' with a parameter named
>'Singleton'.

I could see it as an overload of the "To" function, or whatever we end up naming
it. But its not that big of a deal either way.

>[6] I think it would probably (but not necessarily) be better to have the
>list exceptions gathered into the x.Lists parent package, so that there is
>only one of each exception (rather than one for each instantiation of
>x.Lists.[Unb|B]ounded).

That's most likely true. When we have more than one package we can do that.

>[7] As mentioned, I actually want to remove directional parameters. Instead,
>all that is required is a 'smart reverse' operation. This merely switches an
>'effective forwardness' flip-flop between actually forward and actually
>backward. All the operations must be programmed to behave according to the
>effective forwardness (not difficult).

I'd like to see this, but I should note that the less state-full calls are, the
easier they will be to parralelize. I also get worried whenever I hear anyone
use the word "smart" in the context of a computer program. :-)

(several other parameter naming issues removed)
I'll look into the merits of all these. I don't think we should let parameter
names hold up the works at this point though. We'll never get everyone to agree
that they are all perfect.

>[12] I like the Remove procedure combining retrieval and deletion. This is
>an omission from my own proposal. [13] Maybe 'Old_Element' should be
>'Old_Item'. ([14] Also, I would prefer the name 'Extract' for the
>subprogram.)

I think I like that better too.

>
>Now we come to the vexed issue of iterators.
>
>[13] I have a problem with passive iterators. Texts say that they should be
>provided in addition to active iterators, but I rather feel this is like

Frankly I totally agree with you here. I don't like to use them either. But
several people here do, and were quite insistent that they need to be in there.
Since it doesn't seriously hurt anything to put one in (its not like it has
cascading effects throughout the whole package), I can't really see keeping them
out just because the two of us don't like to use them.

>[14] I feel that the term 'iterator' should be reserved for a construct that
>is applicable to all container types (and which is therefore monodirectional

Since we don't and won't have such a thing, I don't see the sense in reserving
the term for that. 

>[15] The reason why I made cursors internal to list objects (rather than
>providing a separate cursor type) is because an operation on one cursor
>(active on a certain list object) must be able to interrogate and possibly
>update any other cursors (also active on the same list object). With
>separate cursor objects, the only way to do this is for each cursor to
>contain a pointer to the list it is active on, and for each list to contain
>pointers (perhaps in a linked list) to all the cursors active on it. This

That's correct, but what it ultimately requires is that both lists and active
iterators be controlled. I can show the implementation in detail, but the work
required is roughly equivalent to providing a body for this package, which is
what we were discussing doing in the first place.

Fine rationale aside, it appears we have already reached a consensus on using
the controlled iterator approach. The issue under consideration isn't if someone
has another approach which they can argue is better. Clearly you feel you do.
The issue is what we can move forward with. The approach you describe is not
substantially different from the one you presented 2 weeks ago, and the fact of
the matter is that people, for whatever reason, have not been rallying around
it. I don't see any hope in the tide turning in its favor if we wait another 2-4
weeks. 

The strawman has presented 3 different active iterator approaches (each
progressively further from my "ideal" btw). The final one seems to be the one
people want. I'm not nessecarily any happier about that than you are, but that's
the way it has worked out.


>[20] What does Splice do? Is it useful?

See *waaay* previously. I cribbed it from the STL. Its essential for efficiently
putting two lists together.

>
>[21] Why do you provide list serialisation (stream read and write)
>procedures in public, rather than overriding the Read and Write attributes
>of the list type in private?

I've had problems (of an exact nature that I forget) when they were private. So
that's just become my idiom. It could be that the routines could be moved to
just inside of the private section without hurting anything. I'll check it out
when I get a chance.

>Your proposal apparently omits the following vital operations: [22] testing
..
I don't personally consider any of this "vital", and much of it can be done just
fine with an iterator, along with loads of other stuff you haven't thought of
but someone somewhere else considers vital. :-)

The exception is "=", which clearly needs to be redefined or removed. The
default is going to be nonsense.

>[29] Although you have put some documentation into the spec as comments, it
>is not quite as clear or complete as would be ideal. I think it might be
>helpful if this documentation were separated out into a text (or HTML) file.

I agree with this wholeheartedly. I already have one volunteer to work up some
documentation. Unfortunately, he prefers to work in Word instead of HTML(yuk).
But word is (arguably) better than nothing. :-)

You do point out some issues which I think need to be addressed. But the only
ones I'd consider major are issues where it appears we already have a fair
amount of consensus on. The rest is just naming issues.


>Any more thoughts on a (better) name for the project? (Does 'Tenet' tickle
>you at all?)
Perhaps my tonsils a bit. :-)

I'm still stuck on the palindrome issue. Unfortunately, palindromes are one of
the tougher word tricks to work out, so there aren't that many to choose from.
Since Anna is taken, I'd kind of like "ANA" (if someone can get a decent acronym
for it), or "Elle" or "Ele" for personal reasons.

---
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.