Array Aggregates Questions

Array Aggregates Questions

[Geoff Mendal]

Dear Ada fanatics,

We would like to know why it is the case that an array aggregate
that specifies named associations in addition to an "others"
association must be qualified in the following contexts:

  (1) a generic actual parameter
  (2) an expression that follows an assignment compound delimiter

This seems to us to be too restrictive and a search of the
current Ada literature does not provide an adequate justification
for this restriction:

  ARM 4.3(7..8), 4.3.2(4..7), 4.7
  Booch sec 11.2 pp.148-150
  Barnes sec 6.2 pp. 71-72

Consider the following Ada code:

  Aggregate_Examples:
  declare
    subtype Shorty is String (1 .. 5);
    S : Shorty;
  begin
    S := (others => 'A');                       -- #1 valid
    S := ('A', 'B', others => 'C');             -- #2 valid
    S := (1=>'A', 2=>'B', others=>'C');         -- #3 invalid
    S := Shorty'(1=>'A', 2=>'B', others=>'C');  -- #4 valid
  end Aggregate_Examples;

What is the rationale for #3 being invalid? Is it not
the case that a compiler could figure out the subtype of
the aggregate in #3, just as it is able to do for the
other three cases? Since it is generally agreed that use of named
notation is more readable, better Ada style, etc., what
is it about named notation (as used in #3 above) that forces
qualification to be specified in order to determine the subtype of
an array aggregate?

It seems to us that qualification of aggregates is a special-
case in Ada. For instance, consider overloading of enumeration
literals:

  Enumeration_Literals_Example:
  declare
    type Vowels is ('U', 'I', 'O', 'E', 'A');
  
    C : Character;
    V : Vowel;
  begin
    C := 'A';                                  -- valid
    V := 'E';                                  -- valid
    if 'A' < 'U' then ... end if;              -- invalid
    if Character'('A') < 'U' then ... end if;  -- valid
    if 'A' < Vowel'('U') then ... end if;      -- valid
  end Enumeration_Literals_Example;

Note that qualification is not required in all cases here.
Qualification is only required when the enumeration literal(s) 
appear in an ambiguous context. Why is this not the case for
qualification of array aggregates (and aggregates in general)?

BONUS QUESTION:

What will the following function return (and why)?

  function Heck_If_I_Know return Boolean is
    type Multi is array (1..3, 1..2) of Integer;
  begin
    return (1=>(1=>4), 2=>(2=>5)) in Multi;
  end Heck_If_I_Know;

[This runs without exception on the Rolm/DG and returns True]

Geoff & Doug
-------

Re: Array Aggregates Questions

[John Goodenough]

In article <8512110559.AB01317@ucbvax.berkeley.edu> Mendal@SU-SIERRA.ARPA (Geoff Mendal) writes:

>We would like to know why it is the case that an array aggregate
>that specifies named associations in addition to an "others"
>association must be qualified in the following contexts:
>
>  (1) a generic actual parameter
>  (2) an expression that follows an assignment compound delimiter
>
>This seems to us to be too restrictive and a search of the
>current Ada literature does not provide an adequate justification
>for this restriction.

I've been waiting for someone else to respond to your query, but since there
seem to be no takers ...

Let me modify your examples slightly:

    Aggregate_Examples:
    declare
        subtype Shorty is String (3..5);
        S : String (1..6);
    begin
        S(3..5) := (others => 'a');                             -- #1 legal
        S(3..5) := ('a', 'b', others => 'c');                   -- #2 legal
        S(3..5) := (3 => 'a', 4 => 'b', others => 'c');         -- #3 illegal
        S(3..5) := Shorty'(3 => 'a', 4 => 'b', others => 'c');  -- #4 legal
    end Aggregate_Examples;

Suppose in place of #3 we had written:

        S(3..6) := (2 => 'b', 3 => 'c', 4 => 'd', 5 => 'e');    -- #5 legal

This is completely legal, and is semantically similar to assigning a slice,
e.g., S(2..5).  (Of course, after the assignment, S(3) equals 'b' even though
within the aggregate, component 3 had value 'c').  But suppose the aggregate
is written:

        S(3..6) := (2 => 'b', 3 => 'c', others => 'd');         -- #6

Which components of the slice are to receive value 'd'?  The answer depends on
what bounds we give the aggregate.  If we use the lower bound of the index
subtype, then the aggregate is equivalent to ('d', 'b', 'c', 'd').  If we
implicitly qualify the aggregate with the subtype of the lhs, then CONSTRAINT_
ERROR will be raised because 2 is not in the range 3..6.  As I recall, it was
the difficulty of deciding how to treat examples like #6 that led to the
decision to make examples #6 and #3 illegal.

Named notation with an OTHERS clause is allowed for a non-generic actual
parameter and a function result because no implicit subtype conversion is
performed in these contexts; if the bounds of the aggregate do not match the
bounds of the formal parameter or function return subtype, CONSTRAINT_ERROR
will be raised.  In these contexts there is no ambiguity in determining the
required lower bound for an aggregate with an OTHERS clause, so the notation
is allowed.

But now that we have more experience with the language and can see the utility
of allowing examples like #3 when implementing Pascal-like sets, it could be
argued that examples #3 and #6 should be legal, and #6 should raise
CONSTRAINT_ERROR.  If these examples were made legal, a new semantic rule
(loosely stated) might be: if an aggregate has an others clause, it is
implicitly qualified by a subtype having the applicable index constraint.

John B. Goodenough                           goodenou@wanginst        (CSNET)
Wang Institute of Graduate Studies           decvax!wanginst!goodenou (UUCP)
Tyng Road, Tyngsboro, MA 01879               Goodenough@ISI           (ARPA)
(At Wang Institute until 6/1/86)             617-649-9731

Re: Re: Array Aggregates Questions

[stt]

Another way to say this is: when "sliding" is legal,
named-with-others is not (since the bounds are indeterminate).