Possible for Ada 2020: "Cursors" for Arrays

Possible for Ada 2020: "Cursors" for Arrays

[Shark8]

In a few threads a few people have expressed a desire to be able to initialize Arrays based on some formula usually including the indices. In order to do this we need some sort of "cursor"-type/attribute.

So, let us propose a cursor-attribute so that some array type, T1, defined as
  type T1 is Array( 1..10 ) of Integer;
could have a variable initialized as follows:
  V1 : T1:= (others => T1'Cursor'Index)
resulting in V1 getting (1,2,3,4,5,6,7,8,9,10);

This doesn't scale to unconstrained arrays, however because given
  type T2 is Array( Positive Range <>) of Integer
  V2 : T2 := (others => others => T1'Cursor'Index)
becomes ambiguous/indeterminate [lacking any constraints to determine the correct size] -- this could be ameliorated by requiring explicit bounds and throwing a compiler error.

Taking a page from the 'Length attribute we could make the attribute take an optional parameter indicating which of the indices we are referring to.

  -- completely forced example.
  Type CBT is Array(1..8,'A'..'H') of Piece;

  -- Transforms (1,A) to 1, (1,B) to 9, [...], (8,H) to 64
  Chess_Board_Transform : CBT := 
     (others => 8*(Character'Pos(CBT'Cursor(2))-Character'Pos'A') + CBT'Cursor(1) );

Note that because we know the types for the indices we should be able to use the cursor as that type for that index... This would also be a good place for implementation of a 'Type attribute, as matching the 'cursor' to that particular index would entail interrogating the previously known definition for the proper type anyway.

My question: does this look reasonable, or is it just superfluous?

Re: Possible for Ada 2020: "Cursors" for Arrays

[Niklas Holsti]

On 13-06-04 03:09 , Shark8 wrote:
> In a few threads a few people have expressed a desire
> to be able to initialize Arrays based on some formula
> usually including the indices. In order to do this we
> need some sort of "cursor"-type/attribute.

Maybe...

> So, let us propose a cursor-attribute so that some array
> type, T1, defined as
>   type T1 is Array( 1..10 ) of Integer;
> could have a variable initialized as follows:
>   V1 : T1:= (others => T1'Cursor'Index)
> resulting in V1 getting (1,2,3,4,5,6,7,8,9,10);

I think it would be better to build this ability from syntax similar to
the quantified expressions - "for all/some I in <range> => ...". To
avoid ambiguities when the array elements are Boolean we should use a
new keyword instead of "all" or "some". I would also not put this after
"others", but directly as an "array_component_association":

   V1 : T1 := (for each I in T1'Range => I);

But this would make yet another useful word ("each") reserved... Perhaps
we can do without any keyword:

   V1 : T1 := (for I in T1'Range => I);

> My question: does this look reasonable, or is it
> just superfluous?

Superfluous, yes, perhaps with the exception of some corner cases such
as initializing large systematic arrays during pre-elaboration. But nice
to have, why not.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Possible for Ada 2020: "Cursors" for Arrays

[Shark8]

On Tuesday, June 4, 2013 12:19:00 AM UTC-6, Niklas Holsti wrote:
> 
> I think it would be better to build this ability from syntax similar to
> the quantified expressions - "for all/some I in <range> => ...". To
> avoid ambiguities when the array elements are Boolean we should use a
> new keyword instead of "all" or "some".

Why would it matter syntax-wise? (that is, I don't see how there would be a problem when the elements are a boolean-type for the attribute form... that seems to only arise in a situation like you are proposing, jumping off "for all"/"for some" syntactic constructs.)

Re: Possible for Ada 2020: "Cursors" for Arrays

[Niklas Holsti]

On 13-06-04 16:18 , Shark8 wrote:
> On Tuesday, June 4, 2013 12:19:00 AM UTC-6, Niklas Holsti wrote:
>>
>> I think it would be better to build this ability from syntax similar to
>> the quantified expressions - "for all/some I in <range> => ...". To
>> avoid ambiguities when the array elements are Boolean we should use a
>> new keyword instead of "all" or "some".
> 
> Why would it matter syntax-wise? (that is, I don't see how there
> would be a problem when the elements are a boolean-type for the
> attribute form... 

I agree that the attribute form (T1'Cursor) would not be ambiguous, but
I don't like that syntax, nor the use of "others" before it. Just my
opinion, of course. One reason for my dislike is that the word "Cursor"
is already in use for something more permanent (cursors to containers);
another is the problem with unconstrained arrays that you already
showed, a third reason is having to add a rule that the 'Cursor
attribute can be used only in such aggregates.

> that seems to only arise in a situation like you are proposing,
> jumping off "for all"/"for some" syntactic constructs.)

I believe that even using "for all" would not be strictly ambiguous, as
long as one-element positional array aggregates remain forbidden. But it
could be confusingly "almost" ambiguous. The form with no keyword "for I
in <range>" now seems best to me, and sufficiently clear and
sufficiently far from ambiguity.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Possible for Ada 2020: "Cursors" for Arrays

[Adam Beneschan]

On Monday, June 3, 2013 6:09:01 PM UTC-7, Shark8 wrote:
> In a few threads a few people have expressed a desire to be able to initialize Arrays based on some formula usually including the indices. 

http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0061-1.txt?rev=1.1
 
                            -- Adam

Re: Possible for Ada 2020: "Cursors" for Arrays

[Jacob Sparre Andersen]

Adam Beneschan <adam@irvine.com> wrote:

> http://www.ada-auth.org/cgi-bin/cvsweb.cgi/ai12s/ai12-0061-1.txt?rev=1.1

Looks very good.

Greetings,

Jacob
-- 
Black Hole: Where the universe made a Divide by Zero.