From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Ada 2012 Iterators limitations & proposition
Date: Thu, 29 Sep 2011 20:44:18 -0500
Date: 2011-09-29T20:44:18-05:00 [thread overview]
Message-ID: <j636tk$vd6$1@munin.nbi.dk> (raw)
In-Reply-To: 37a42bc3-9efa-43b2-bf37-6198dc6ecf2b@db5g2000vbb.googlegroups.com
"David Sauvage" <david.sauvage@adalabs.com> 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.
next prev parent reply other threads:[~2011-09-30 1:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-29 12:31 Ada 2012 Iterators limitations & proposition David Sauvage
2011-09-30 1:44 ` Randy Brukardt [this message]
2011-09-30 15:39 ` David Sauvage
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox