CVS difference for ai05s/ai05-0139-1.txt

Differences between 1.5 and version 1.6
Log of other versions for file ai05s/ai05-0139-1.txt

--- ai05s/ai05-0139-1.txt	2009/06/09 01:53:16	1.5
+++ ai05s/ai05-0139-1.txt	2009/10/23 06:06:31	1.6
@@ -1164,3 +1164,77 @@
 than to say that designers are clever and come up with structures that no one expects.
+From: Bob Duff
+Sent: Wednesday, June 17, 2009  4:17 PM
+> I understand the desire
+> for a *syntax* approximating:
+>      for Element in Container loop
+>         ...
+>      end loop;
+> But I see no requirement that this means we somehow have an iterator 
+> built into the Container itself.
+I strongly agree.  Eiffel went this way (state of iterator in the container) early on,
+and it's a disaster.
+A "for Element in Container" kind of syntax should not imply cursor-state-in-container
+any more than "for I in 1..10" implies that any Integer contains a "current Integer"!
+>...Also, we would certainly want to allow  multiple tasks to iterate 
+>over a Container in parallel, I would think,  or to allow nested 
+>iterators such as:
+>      for Left in Container loop
+>         for Right in Container loop
+>            Try_Pair(Left, Right);
+>         end loop;
+>      end loop;
+> I think the above *syntax* should always presume there is an anonymous 
+> iterator object created, and that is what carries the state of the 
+> iteration.
+> In any case, I wonder whether it is the strange nature of this generic 
+> that is creating the problem, or is there a common need to be able to 
+> define in a single package two recursively-dependent types one of 
+> which is based on a generic instantiation of the other.  I suppose 
+> this is a very hard question to answer...
+> Thanks for the example!
+Yes.  It's an interesting and useful example.
+> I had proposed
+>     for Element in Container.Iterator loop
+>        ...
+>     end loop;
+> (where "Iterator" is a function returning an anonymous iterator object).
+That's OK, but "for Element in Container" could be some sort of short-hand for
+"the default iterator".  E.g. the one that goes forward, and you need to say
+something extra to get the backward one.
+> Since we're using that same sort of model for accessors (there is an "extra"
+> discriminant reference in those), I don't see the problem. But of 
+> course, I was always happy with this formulation, it is other people that were not.
+> With the accessor proposal, you have to write a single extra 
+> selection; that seems fine to me for iterators, too. Since it would 
+> not be surprising to use both of them together, it would actually be 
+> kinda weird to have simpler syntax for the iterator and not the accessor:
+>     for Cursor in Container.Iterator loop
+>         Container.Accessor(Cursor).Element.Component := 10;
+>     end loop;

Questions? Ask the ACAA Technical Agent