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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!info-ada
From: Mendal@SU-SIERRA.ARPA (Geoff Mendal)
Newsgroups: net.lang.ada
Subject: Array Aggregates Questions
Message-ID: <8512110559.AB01317@ucbvax.berkeley.edu>
Date: Wed, 11-Dec-85 00:50:41 EST
Article-I.D.: ucbvax.8512110559.AB01317
Posted: Wed Dec 11 00:50:41 1985
Date-Received: Fri, 13-Dec-85 07:53:04 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
List-Id: <comp.lang.ada>

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