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.7 required=5.0 tests=BAYES_00,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC 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.2 9/5/84; site wanginst.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!linus!wanginst!goodenou From: goodenou@wanginst.UUCP (John Goodenough) Newsgroups: net.lang.ada Subject: Re: Array Aggregates Questions Message-ID: <1478@wanginst.UUCP> Date: Fri, 20-Dec-85 14:52:39 EST Article-I.D.: wanginst.1478 Posted: Fri Dec 20 14:52:39 1985 Date-Received: Sun, 22-Dec-85 01:31:25 EST References: <8512110559.AB01317@ucbvax.berkeley.edu> Reply-To: goodenou@wanginst.UUCP (John Goodenough) Organization: Wang Institute, Tyngsboro, Ma. 01879 Summary: Why the restriction on others and named notation exists List-Id: 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