Re: GCC 4.0 Ada.Containers Cursor danger.

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

On Fri, 08 Jul 2005 00:12:11 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 07 Jul 2005 12:38:57 +0200, Georg Bauhaus wrote:
>> 
>>>> Otherwise iteration using cursor
>>>>would be impossible.
>>>
>>>Why? A cursor designates an element. There are operations
>>>on cursors, some of them let us move a cursor from one
>>>element to another. Then the cursor designates another element.
>> 
>> Rather it does some element at another location.
> 
> As long as we have no clear definition of "location",
> the argument can go on.

That's easy. Enumerate all elements in the container [i.e. define an order
there.] Location will be that number 1..n.

> Certainly there are relative
> locations if you think of a List say, this element comes
> before that. There are locations implied by sorting order.
> But sorting order depends on the comparison, so location
> is in fact not a spatial position, but there is a position
> in some sorting order. Which then isn't fixed per
> element in a container.

Yes.

> Then I might imagine an element
> designated by a cursor to have a place in some imaginary
> picture, hence to have a location. But I can dispense with
> a location when the container's cursors actually synthesize
> the elements on read, so elements don't exist at all before
> --in this imaginary implementation-- my program dereferences
> a cursor. The elements could be stored in some electrically
> charged gel, highly dispersed. Or I could be your container
> as long as my operations will give you what the operation
> descriptions tell. Do I have to tell you where (and whether)
> I store your information in locations?

You did, if elements are ordered.

>> The element is of little
>> matter here (for this concrete case, note.) Otherwise "Replace" would have
>> no sense.
> 
> Sorry, I don't understand this.

Replace =  "to take or fill the place of". Notice "the place of"! (:-))

>> BTW the parameters of the type Cursor are routinely named
>> "Position"!
> 
> Anything better?

"Element", isn't cursor <=> element? (:-))

>>>I don't think there an implied requirement to think of locations.
>> 
>> Then you have to throw out "Next", "First" etc.
> 
> I don't understand. I'm just thinking in terms of elements
> and cursors that designate elements.

But the elements type don't have "Next" and "First". If Integer X is in A
then Integer'Succ (X) is not necessarily in A. And A'First is not
necessarily Integer'First.

> There are subprograms
> named Next, First, etc. with a description of what they do.
> Where is the pressing need for a location? How do you use
> "location" in your programs?

A (Location) := X;

>> It is the location that tells you what's next.
> 
> Next is providing me with something that designates
> another element, or No_Element.
> To me, that's what is next, plus what Has_Element says.
> By the operations of Next, First, etc., I don't know yet what's
> next. I will know what is next when I look at the element
> designated by the next cursor, after Next's execution.

>> As I said before, it is difficult if possible to assign any definite
>> semantics to cursors, such that would be consistent across all operations
>> on them.
> 
> Could you explain some inconsistencies among the Cursor
> operations?

What is the semantics they implement? See your example with Next. We have:

1. An order defined on elements (=locations in some "pre-container" (:-))
2. An order defined by the container (=locations)
3. Instances of elements (value semantics)
4. References to elements (=locations in some third container! (:-))

We need to define what "Next" does in terms of 1-4. I doubt you will be
able to define it without 2. Note that you could replace 2 with

2.a A membership test for an element to be in the container

But then 2 could be trivially derived from 2.a and 1. In other cases 2
could be an order completely unrelated to 1, like it is in the case of
unsorted arrays.

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