Re: A few questions

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ojkj222dh308.y5p6iz7kqgjc.dlg@40tude.net...
> On Tue, 17 Nov 2015 15:30:28 -0600, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:8hw612c7lfik.1cy0uanjjnpzv$.dlg@40tude.net...
>>> On Mon, 16 Nov 2015 13:13:05 -0600, Randy Brukardt wrote:
>>>
>>>> You're speaking nonsense. The element is part of the container, and the
>>>> only way to access it is from the container.
>>>
>>> I think you are confusing indices with iterators. The very concept of 
>>> the
>>> iterator is accessing elements without the container as opposed to the
>>> index.
>>
>> That's surely not my idea of an iterator. And it doesn't work for Ada in 
>> any
>> case, as that would allow altering elements of constant containers (we
>> prevent that in the containers library by requiring an "in out" container
>> parameter in all cases where modifications are allowed).
>
> Access /= Update. Compare it with "access constant T"

True, but irrelevant. Iterators without update compatibilities are way to 
limiting to be of any value.

> The difference between index and iterator is that accessing through the
> index requires the container. An index is always relative to some
> container. The iterator does not need the container, the container is
> implicit.

This is the confusion between "iterators" and "cursors" that the C++ 
libraries have. What you are describing as an "iterator" is exactly the 
definition of a cursor in Ada. To me, iterators are active objects, not just 
indexes.

>>> Both concepts of
>>> iterator and index have fundamental operations to create a new instance
>>> referencing some other element (next, previous, sibling, parent, 
>>> neighbour
>>> etc)
>>
>> The C++ containers mix up the ideas of iterators and cursors (they're
>> essentially the same thing there). By your description, you want them to 
>> be
>> the same -- but in that case, just use the cursors and be done with it. 
>> You
>> will sacrifice safety and ease-of-use to do so, but whatever.
>
> That is not my point. It is that Index + 1 is another index and that
> Iterator.Next is another iterator. From the interface point of view you
> don't need the container to get another instance of either.

Next(Cursor) gets you another Cursor. (You can't use the prefix notation 
because Cursors aren't tagged, and that's because we can't have primitive 
operations of two tagged types, else they would have been tagged. But 
otherwise this is identical.) You don't need the container to call Next. But 
you do need the container to update the element.

> And regarding safety, it is very important that you don't need the
> container when accessing elements or advancing the iterator. Well-designed
> iterators meant to keep the iteration state *inside* the iterator object
> rather than in the container, for evident reasons.

???

If the container (not counting the contents of the elements) is modified 
while the iterator is executing, it doesn't matter where the iteration is 
happening -- you're not going to be able to maintain the invariants of the 
execution.

That happens with explicit iteration in the Ada.Containers (that is, 
directly using Next and Cursors) -- where the effect is for the user to 
figure out (and it's often erroneous) -- and that happens with any possible 
iterator mechanism (using call-backs, or interfaces, or whatever) -- where 
Ada uses a tampering check to avoid problems (the container does not allow 
element insertions or deletions while an iteration is running).

If you think allowing erroneous execution is somehow safe, you're in the 
wrong language forum.

                            Randy.