Re: A few questions

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

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

>> You can't create a reference to an
>> element of a container without having the container. But your proposed
>> interface does not have the container anywhere. How does the reference 
>> get
>> created???
>
> From the old reference of course. Iterators are pointers.

Nonsense.

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

>>>> Making a language "more expressive" is code for "easier to write", 
>>>> which
>>>> never was a goal of Ada.
>>>
>>> That's one of the issue here. The goal for Ada, as I understand it, has 
>>> always
>>> been to be "easier to read". There is no reason why "easier to write" 
>>> should
>>> be in opposition to that goal.
>>
>> "Easier to write" almost always is in opposition, because it means using
>> shorthands that cannot easily be deciphered by a human. The "for E of
>> Container loop" is certainly in that category, we only allow it because 
>> no
>> one other than implementers need to understand how it works in detail. 
>> The
>> way one expects it to work is in fact how it works when read - but if you
>> need to understand the details, it's a disaster.
>
> A disaster is when nobody can understand the details. The concept of
> iteration is simple, so an implementation of its syntax sugar (nothing 
> more
> than sugar) must be easily readable and writeable, since all work is
> already done in the container.

Well, that's what we did, but you don't seem to be able to see it. Can't 
help with that...

                   Randy.