Re: A few questions

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1705bpj6jrld0.1lc44o5yo6bj7$.dlg@40tude.net...
> On Fri, 13 Nov 2015 11:52:29 -0600, Randy Brukardt wrote:
...
>> 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.

I am. :-)

You'd probably keep some state in the iterator object (some access to the 
file, at a minimum, possibly a buffer). The "cursor" would be the character. 
Each call to Next would put the following character into the "cursor". 
Easy-peasy. :-)

Thinking of an iterator "cursor" as having to be some sort of index obscures 
the real possibilities of the interface.

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

We're not talking about arrays, we're talking about iteration. And for this 
purpose, "cursor" could just as well be called "blob". It's a type parameter 
to the interface, nothing more. One might give it additional semantics for 
some particular implementation, but that's not inherent in the model.

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

An iterator is an extra data type. And you surely don't need to involve 
pointers, if copying the element is OK. If you want to modify the element in 
place, then some sort of pointer is always required (outside of the built-in 
array type).

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

Definitely not, in the iterator interface. It is anything you want it to be. 
Surely, for discrete unmodifiable values, it's better that the "cursor" be 
directly that value. (The read from a file example, the prime numbers 
example, and the OPs example all have this property.) "Cursor" is just the 
name of the type in the generic interface. Just because it has that name 
(and is commonly used as an index), doesn't mean that it always has to be 
used that way.

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

Your description points out the problem: it's "a set", at which point a set 
implementation is appropriate. And the implementation is identical to any 
other set, so there is almost no value to having a separate bag 
implementation (it provides no performance improvements over an ordered set, 
for instance).

Whether its useful or not is irrelevant -- it is indistiguishable from any 
other set (the extra operations having no effect or overhead if not used). 
So there is no real value to having a separate Bag abstraction.

                                         Randy.