Re: discriminant questions

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

On Wed, 21 Sep 2011 13:51:43 -0700 (PDT), Maciej Sobczak wrote:

> On Sep 21, 9:48�am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>> Nobody is forcing referential semantics, although it might be the most
>>> natural and efficient solution for iterators.
>>
>> Of course it does, because the iterator refers to the container and to an
>> element in that container.
> 
> Not necessarily.
> 
> Think about a map. Let's say a map with strings as keys.
> We can say that strings are associated with values in the map and that
> strings allow to obtain those values. But can we say that strings
> refer to those elements?

Strings alone do not. In a combination with a reference to the map, that
new object does.

> So let's define the iterator as an entity that is associated with the
> element in a container and that allows to obtain that element.

String is not an iterator according to this definition. It is also not an
index (with operations Succ, Pred, or that I in A and J in A => I+J/2 in
A).

For generic programming the properties of the index, key, iterator must be
stated.

> So - no referential semantics is needed to define iterators.

The validity of an iterator does not depend (pretends to) on other objects
(unconditional). The validity of an index is conditional to the object the
index is being applied.

This is the semantic difference between them from which the usage and other
issues like types relationships follow.

>> Which is evidently fragile as any reference when
>> the container and its element mutate.
> 
> That is, the validity of an iterator is tied to the mutability of the
> container. It is fragile in the same way as array indices, since they
> become invalid when the array is reorganized.

An index is neither valid nor invalid without a context. When index and
container are combined into an iterator bound to certain element of the
container (whereas the element's identity definition is a separate issue,
let's for a while consider that there is a way to identify the element),
then that reference might become invalid.

The point is, when you use index as an iterator you get all problems of the
latter.

Indices are *assumed* to change when the container mutates.

>> It is also bad for generic
>> programming, because the semantics of the side-effects depends on the
>> implementation, i.e. the internal structure of the container.
> 
> Not convincing - generics are supposed to have well defined specs.

I meant rather generic programming = programming in terms of sets of types.

> If
> you worry about your side effects being bound to implementation, then
> there is something wrong with your model of generics. Don't blame
> iterators for this.

I blame them because these differences, essential to container usage,
cannot be promoted at the interface level. Consider a generic
implementation of removing all elements of the container using iterators:

   This := Container.First;
   while This /= Null_Iterator loop
       Next := This.Next;
       This.Delete;
       This := Next;
   end loop;

This may work or not depending on the semantics of Delete. E.g. for a
circular list, it will loop forever.

Note that referential semantics has its place. My concern is its overuse
for things which don't require it, or even cannot provide it, e.g. arrays.

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