Re: A few questions

[briot.emmanuel@gmail.com]

> No, you couldn't, because there still is no way for the compiler to identify 
> the container to pass to the Reference aspect.

You seem to be mixing the particular implementation you would use with
what the standard should allow. There is nothing in the spec of a reference
type that mandates knowing the container (and the way it currently is done
in the implementations is to use a 'Unrestricted_Access, which is ugly to
say the least).

> If you mean to magically extract it from the call to Depth_First_Search, I 
> would be strongly against as there is no need for an actual container object 
> for an iterator (and the model specifically was designed to allow that 
> possibility). It would be *much* more limiting to assume a container.

If I want my iterator to implement depth_first_search, it would indeed need to
know the container (like most iterators would need to know the container,
in fact). The reference type itself (the end product of the iteration) doesn't
need to know that though. The container is necessary for the iteration or
traversal of itself, but certainly not once you manipulate an element.

My example assumed nothing.

The implementation you seem to have in your head seems indeed to assume
a lot of unnecessary things.


> Definitely a lot more complicated than what we have (and what we have is too 
> complicated).

What we have is both too complicated and too limited. Too complicated because
nobody that hasn't spent a full week will be able to explain how the aspects
combine with iterators to end up with cursors and the for-of loop. They just
happen to work for existing containers, but as this thread has proven, anyone
who tries to actually implement them for other uses that the few official
containers quickly hits sever limitations.


> 
> >    for E of G.Breadth_First_Search loop   --  breadth first search, get 
> > element
> >        null;
> >    end loop;
> 
> Again, how does the compiler know that G is the container in this iterator? 
> "G.Breadth_First_Search" is just a function call. On top of which, you now 
> have two different and unrelated expected types for the iterator, which 
> would be a new concept in Ada.

It is a function call that returns the iterator. So obviously it is allowed to have
a relationship between the return value and the parameters. The iterator
is therefore allowed (but not mandated, that would depend on the actual
container we are talking about) to have a reference to the container.
This is called flexibility. Something lacking in the current standard.

I do not understand your last sentence about the two unexpected types.

> Making a language "more expressive" is code for "easier to write", which 
> never was a goal of Ada.

That's one of the issue here. The goal for Ada, as I understand it, has always
been to be "easier to read". There is no reason why "easier to write" should
be in opposition to that goal.

> > I like to clearly
> > state what I mean in the code, but on the other hand why should I have
> > to specify "Element (C)" when I can just use "E" ?
> 
> Readability, of course. I don't believe that you should ever have been 
> allowed to just specify E. I lost that argument 'cause it wasn't 
> sufficiently evil to waste scarce political capital on, but I don't see any 

Now I understand. You are re-fighting a fight you lost apparently. But from
talking to all my colleagues (all of whom are of course Ada experts), we all
much prefer the form with just "E" in practice. So that change was a great
improvement in the standard, if not quite wide reaching enough.