Ada 2012 Iterators limitations & proposition

Ada 2012 Iterators limitations & proposition

[David Sauvage]

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.

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.

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.
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;

      -- access both index/key & element
      for Key, Element of Data.Processors loop
         Process (Key, Element);
      end loop;

      -- access to element only (2)
      for null, Element of Data.Processors loop
         Process (Element);
      end loop;

      -- access to element only (2), for compatibility
      for Element of Data.Processors loop
         Process (Element);
      end loop;


Cheers

Re: Ada 2012 Iterators limitations & proposition

[Randy Brukardt]

"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.

Re: Ada 2012 Iterators limitations & proposition

[David Sauvage]

> 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.

Oh, sorry I forget about that.

Excellent,

Cheers