Re: A few questions

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

On Fri, 13 Nov 2015 16:15:01 -0600, Randy Brukardt wrote:

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

It would be nice to see a demonstration for iterating lines of a text
file... (:-))

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

And a pointer to the container.

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

A bag need not to be sorted, no overhead to keep the order, no need for
elements to have "=" and "<".

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

It is. The implementation will likely choose a singly linked list of
element buckets.

> So there is no real value to having a separate Bag abstraction.

Even if the implementation were same, abstraction is called abstraction
because it is not implementation.

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