CVS difference for 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.
+
+Yes.
+
+> 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;
+
+Hmm...
+
+****************************************************************
Questions? Ask the ACAA Technical Agent