Re: A few questions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 13 Nov 2015 11:52:29 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1dolqizyi8gxi.t3173bhifuu1.dlg@40tude.net...
>> On Thu, 12 Nov 2015 15:15:45 -0600, Randy Brukardt wrote:
> ...
>>> Surely it is not the same. But why do we need the first?
>>
>> For doing this:
>>
>>   for Line in Read (Text_File) loop
>>       ...
>>   end loop;
> 
> Note that you used "in" rather than "of" here.

Yes, because Ada always had this syntax for iterating elements of a set. It
is:

   for I in A'Range loop

It is not

   for I in A loop

If the later were legal then loop parameter must have been a pair (Index,
Element), because that is what an array is: a set of pairs.

[ "of" is rubbish of course. It is "in" that iterates / enumerates a set.
If "of" should ever be used then for something else. ]

> And if you did that, there is 
> no problem implementing this in the existing Ada, even as you suggest.

I am not sure about that.

>> Operation Read provides an iterateable container-view of Text_File. There
>> cannot be any index, because the "buffer" will contain just single line.
> 
> A "cursor" is not necessarily an array index, as I pointed out earlier in 
> this thread.

Array does not contain "cursors." Cursor is an evil idea, but that is
unrelated to the issue of iteration over a general set.

>>> An array is surely
>>> a container, and we got along just fine for 30 years without being able 
>>> to iterate elements of arrays.
>>
>> Not every container is an array. There are lots of containers which
>> semantically have no index.
> 
> Then provide an iterator implementation where the cursor is an access to the 
> element.

Why do I need extra data types, bad types as they involve pointers?

>>> There is always *something* that works as an index. If there isn't, you
>>> can't iterate (because you can't figure out a reproducible order for 
>>> which
>>> item is next).
>>
>> First, index is more than iteration. Index assumes random access and an
>> ability to access any number of times. Iteration requires only sequential
>> access and only visit once. If you equate both, you either burden the
>> implementation with unnecessary functionality or the clients in order to
>> catch unsupported actions. Not good.
> 
> You are giving more properties than necessary to an iteration cursor (which 
> is what we are talking about). There is absolutely no problem with it 
> providing sequential one-time access. You have to program it that way, of 
> course, but it's not hard to do (see the implementation in the ACATS, for 
> one example).

Maybe yes, maybe no. But cursor is neither index nor element. Cursor is
same as a pointer.

> I might have confused you by calling it an "index", because it's clear that 
> you're assigning properties to it that I am not. There's no reason that you 
> have to use a for loop parameter as an index! (I often write traditional 
> loops where the loop parameter is not an index.)
> 
>> Secondly, it is an implementation driven view. The problem space may have
>> no index even when the implementation could have one. Exposing
>> implementation details is bad.
> 
> That's the Bag arrgument again. I think that particular data structure is a 
> fraud, because it cannot be created in practice -- plus you have to have 
> some sort of access to the elements, so you end up with a cursor of some 
> sort anyway.

No way. The bag is a set that only supports insertion and iteration.
Nothing more. It is very useful, e.g. to hold strong references to
allocated data. References are thrown into a bag. At some point the bag is
iterated and all references invalidated releasing resources.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de