From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,515dd4aa774454a2 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.8.229 with SMTP id u5mr43569163pba.0.1317347061728; Thu, 29 Sep 2011 18:44:21 -0700 (PDT) MIME-Version: 1.0 Path: lh7ni7930pbb.0!nntp.google.com!news1.google.com!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada 2012 Iterators limitations & proposition Date: Thu, 29 Sep 2011 20:44:18 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <37a42bc3-9efa-43b2-bf37-6198dc6ecf2b@db5g2000vbb.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1317347060 32166 69.95.181.76 (30 Sep 2011 01:44:20 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 30 Sep 2011 01:44:20 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Xref: news1.google.com comp.lang.ada:18213 Date: 2011-09-29T20:44:18-05:00 List-Id: "David Sauvage" wrote in message news:37a42bc3-9efa-43b2-bf37-6198dc6ecf2b@db5g2000vbb.googlegroups.com... > Ada 2012 Iterators are very convenient by avoiding the user creating a > procedure that will be used via quote access to iterate. > > The problem (may be a feature for some) is that, by hiding the > indexing it only gives the user an access to the Element of the > container/array, but no access to the corresponding key/index. This is not true. You have access to either the index or the element (but not both). I did not think (and still do not think) that the element version is necessary or all that useful. (It's "cool", though.) Most of the time you would want to use the index (cursor) form. When you write something like: for Index in My_Container.Iterator loop you have easy access to the elements using the indexing forms, so there is little need for direct access to the element. Specifically, you could write a loop to bump a count in every element of a container as follows: for Index in My_Container.Iterator loop My_Container(Index).Count := My_Container(Index).Count + 1; end loop; -- essentially the same thing you would have written if My_Container would have been an array. In this case, you don't need the index for anything else, so you could use the element form as well: for Element of My_Container loop Element.Count := Element.Count + 1; end loop; These have the same semantics and will generate the same code. > I think it would be interesting to be able to have a read-only access > the key/index. This is the only reason why I can't use this new > features every time I want it. You have it, just use the index form, not the element form. (I think that using the index form requires calling the Iterator function for the appropriate container; the element form does this automatically -- but that allows the index form to support alternative iterators, like the form with the optional "Start" parameter that is available for the lists, and the Iterate_Subtree that's available for the trees.) > The only challenge is to declare the key and the element variable > instead of only the element, here is what I would propose to avoid any > language impact ; > Allow the user to specify 2 variables, separated by a comma. > If only one variable is present, it will be affected the element, > If two variables are present, the first is the key/index, the second > is the element. I think this would be very confusing, as you would have two names to represent the element. > The user could specify null instead of a variable name, if he only > wants the key/index for example. > Specifying null for key/index and element would not be legal. > > -- access only index/key > for Key, null of Data.Processors loop > Process (Key); > end loop; This form is not necessary, as it already exists. (It just uses the familar "in" syntax, not "of".) > -- access both index/key & element > for Key, Element of Data.Processors loop > Process (Key, Element); > end loop; As I mentioned, I think this would be very confusing to the reader. Data(Key) and Element would both represent the same element, and there would no reason to choose one over the other. Aliasing of names is usually something to avoid. Randy.