Re: A few questions

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

On Thu, 12 Nov 2015 15:15:45 -0600, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:hs9mu83acmqt$.5liwfglzrr7q.dlg@40tude.net...
>> On Thu, 12 Nov 2015 12:28:46 -0600, Randy Brukardt wrote:
>>
>>> Personally, I find the "of" form unnecessary; we've iterated arrays for
>>> decades without direct access to the element (using the "cursor", that is
>>> the array index), so why are containers different?
>>
>> Of course it is different. Index does not iterate array, it does the
>> array's index range. That is the difference.
>>
>> You can iterate elements of a container or indices of a container. It is
>> not same.
> 
> 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;

Operation Read provides an iterateable container-view of Text_File. There
cannot be any index, because the "buffer" will contain just single line. 

Providing index will be error-prone and cause run-time overhead (index
checks). Add here naming issues, you need a name for the container-view:

   for Line_No in Read (Text_File) loop
       declare
           Next_Line : String := ??? (Index + 1);  -- Oops!
       begin
           ...
       end;
   end loop;

An array interface would promise more than there actually is. It would be
bad design.

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

> There is absolutely no difference for any other 
> sort of container (especially as the array syntax can be used for any 
> container).

It cannot be, e.g. for a general case graph, but that is another story.

> Iterating on elements of a container is unnecessary overkill. (It's also 
> harmless overkill, unlike, say, anonymous access types).
> 
>>> Especially as the
>>> indexing form works on all of the language-defined containers (you never
>>> need to explicitly call Reference or Element). So an "in" iterator looks
>>> just like the array iteration that we've been using from the beginning of
>>> time. What's so hard about that?
>>
>> There could be cases when a container does not have any natural index. E.g.
>> a bag, a set, a files directory etc. You could iterate elements of without
>> inventing indices. Especially when the index is volatile. Consider an
>> implementation that gets a result set of a DB query and then iterates the
>> result.
> 
> 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.

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.

> In any case, Ada does not support iteration without something 
> being a cursor; the "of" form of iteration is a direct translation of the 
> "in" form of iteration (it's purely syntactic with no semantics of its own).

Yes, Ada has a lot of issues with abstract interfaces.

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