Re: RE: RE: list strawman

[Ted Dennison<dennison@telepath.com>]

In article <mailman.1010519822.5637.comp.lang.ada@ada.eu.org>, Steven Deller
says...
>
>Actually, a "split" is not necessary if there is a way to compare two
>iterators to see if they are pointing to the same item -- in that case,
>the left and right partitions can simply be the list portions before,
>and after a given iterator.

This isn't explicit from the current strawman I'm afraid, so it bears publicly
stating:

The current implementation implies that "=" is available for both lists and
iterators (they are not limited types). Given this, we can either take steps to
make "=" no loger available (which was not done), or we can make it do sensible
things.

"Sensible things" to me would imply that for lists, it returns True if they have
the same number of elements, and each element in one list returns True for "="
with the element in the same position in the other list. For an iterator, it
implies that both iterators refer to the same element in the same position on
the same list.

Therefore, unless there is general disagreement with the above, "=" on iterators
should fit your requirement.


>Of course that means the algorithm will need O(lnN) iterators, which is
>another difficulty in the current interface.  I'm not sure why there
>needs to be a limit on the number of iterators.  For any operation that
>has to check consistency across all iterators, just traverse a "list" of
>the iterators (such a list being a locally defined and used list).

There is no limit on iterators in the current. You can make as many iterators as
you like. The implementation I'm working on doesn't even use dynamic allocation
for them or when working with them, so such an algorithm shouldn't be a big
efficiency problem either. But I'd have no big problem with adding a Split
either.

>From my "usability" view, the interface now has 3 flaws:
>  1. No "split" list into two lists
Again: this can be taken care of, if there is support for it.

>  2. No "compare iterators" (at least not that I recall)
Its there, it just hasn't been very well advertised.

>  3. Limited number of iterators
Nope. Never was such a limit in any of the strawmen. (This was a feature of some
of Nick's examples. Are you perhaps thinking of that?)

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