Re: A few questions

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

<briot.emmanuel@gmail.com> wrote in message 
news:64a2a1bd-7519-4d66-bfb6-9b2a1fb1773b@googlegroups.com...
>> Huh? You are suggesting an alternative description for the existing
>> iterators for the existing containers. (If you're suggesting anything 
>> else,
>> you're wasting everybodies time, 'cause something that won't work with 
>> the
>> existing containers is a non-starter.)
>
> I am trying to think of things should have been done, so that perhaps we 
> can find a
> way to fix them in future versions of the language. As this discussion as 
> shown, there
> are lots of very knowledgeable people who are having difficulties with the 
> current
> design and its limitations. If you think this is wasting your time, by all 
> means feel free
> to ignore this thread. I have found it pretty interesting so far.

I haven't been ignoring this thread, although I probably should have rather 
than feeding the trolls.

> "there are lots of very knowledgeable people"

When it comes to Ada, there are very few knowledgeable people (sadly), so 
any statement starting with "lots of knowledgeable people" is junk on its 
face. The only real issue that I've heard from a knowledgeable person is the 
parameter mode issue (which is always an issue with OOP and Ada, it's not 
unique here), and there is a very standard approach to mitigate the problem 
(the Rosen technique).

Everything else seems to come from people who want to do C++ or some other 
language-de-jure in Ada, and that sort of thing has almost always led to 
making Ada more complex without adding anything of value (anonymous access 
types, interfaces, etc.)

>> And the Reference function in the
>> existing containers (and in any container I can imagine) takes a 
>> container
>> parameter. That parameter has to come from somewhere, and it can't come 
>> from
>> the iterator interface (it doesn't include a container in the 
>> description).
>> So where does it come from??
>
> I was talking of the Reference_Type (which doesn't need a container in the 
> public
> spec, although it is convenient sometimes to have one to ensure the 
> lifetime of
> the container is greater than that of the reference -- with all the 
> additional
> performance costs).

I'm still confused. Where does the value of the Reference_Type come from? It 
has to come from the call of some function. (More below.)

> The Iterator interface is an interface, so of course it doesn't contain 
> anything. An
> actual Iterator implementation is free to store a reference to the 
> container if it needs
> it to implement complex algorithms. An iterator could return a reference 
> by building
> it directly, it doesn't need to go through the Reference function for 
> this.

Building it directly from what? An iterator (in Ada today) is an interface 
of functions that are called to implement the iteration syntax. Are you 
proposing to scrap that model? If so, then you have to explain how an 
iterator type maps to iteration syntax. If not, then you have to describe 
the functions called and where in that syntax.

One way to do that latter would be to create additional iterator interfaces. 
*That* would work, rather than additional aspects that don't connect to 
anything. In that case, the function that created the reference type would 
take a value of the iterator object.

That could look something like (names would of course be TBD, "EB" is in 
honor of you, of course):

generic
   type Cursor;
   with function Has_Element (Position : Cursor) return Boolean;
   type Reference_Type is private;
package Ada.EB_Iterator_Interfaces is
   pragma Pure (Iterator_Interfaces);

   package II is new Ada.Iterator_Interfaces (Cursor, Has_Element);

   type EB_Forward_Iterator is limited new II.Forward_Iterator with null 
record;
   function First (Object : Forward_Iterator) return Cursor is abstract;
   function Next (Object : Forward_Iterator; Position : Cursor)
      return Cursor is abstract;
   function Reference (Object : Forward_Iterator; Position : Cursor)
      return Reference_Type is abstract;

   -- Similarly for Reverse_Iterator.

end Ada.EB_Iterator_Interfaces;

Then one could explain the mapping of iterators to references via calls to 
Reference, and the relationship with the other iterators.

As previously noted, I'm unconvinced this is a good idea, but at least the 
above would work. Your proposals are leaving out steps that have to be 
defined in order for it to be a language feature.


>> You're speaking nonsense. The element is part of the container, and the 
>> only
>> way to access it is from the container. You can't create a reference to 
>> an
>> element of a container without having the container. But your proposed
>> interface does not have the container anywhere. How does the reference 
>> get
>> created???
>
> I'll forward you to the discussion you are having with Dmitry. Your notion 
> of
> Index vs Cursor vs Iterators seems to be wrong.

No, his notion of index vs. cursor vs. iterators is nonsense. That's typical 
for him, he uses his own definitions for things, whether or not they have 
anything to do with the subject at hand. It's something one learns to ignore 
here (it's pointless to argue with him about it).

The only definitions I use are the ones in the Ada Reference Manual. All 
else is irrelevant to me.

>> I'm mapping iteration onto the existing containers. That is 
>> straightforward
>> with the existing description,
>
> No it is not. Anyone who has already tried to implement their own 
> iterators
> has failed the first time (at AdaCore, but also Simon Wright in the 
> initial
> message here, at courses we have given in various places,....)

That's the effect of the lack of good examples more than any problem with 
the interface. Brad's ACATS tests provide some good examples for users to 
study, hopefully examples like that will get more play.

>> The limitations aren't that severe, and seem mostly to be related to 
>> having
>> the iterator object be an "in" parameter. (That's probably happened 
>> because
>> "in out" parameters on functions seem weird, but they clearly make more
>> sense in this case.)
>
> I'll stop this discussion which indeed is leading nowhere. You started by 
> saying
> that for-of is useless, so all the rest is moot from your point of view. I 
> can
> understand where you are coming from. You can't understand where we want
> to go.

I think I do understand where you want to go, and I really don't think Ada 
should be going there. Certainly not for sequential programs (I'm more open 
to change on the parallel side because what we have is way too hard to use).

                                Randy.