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,
	MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!ut-sally!ut-ngp!shell!jon
From: jon@shell.UUCP (Jon M. Holdman)
Newsgroups: net.lang.ada
Subject: Re: subaggregates???
Message-ID: <133@shell.UUCP>
Date: Tue, 11-Feb-86 14:03:16 EST
Article-I.D.: shell.133
Posted: Tue Feb 11 14:03:16 1986
Date-Received: Fri, 14-Feb-86 06:28:49 EST
References: <8602090804.AA11771@ucbvax.berkeley.edu>
Organization: CS Dept., Shell Development Co., Houston
List-Id: <comp.lang.ada>


Geoff Mendal writes:
>	procedure Agg is
>	    type R is
>		record
>		    X : String (1 .. 2) := (others => 'z');
>		    Y : String (5 .. 6) := (others => 'z');
>		end record;
>	     A : R;
>	begin
>	    A := (others => (others => 'a'));
>	    A := (X | Y => (others => 'a'));
>	    A := ((others => 'c'), (others => 'c'));
>	end Agg;
>
>Now the question is:  Should any of these assignments raise
>Constraint_Error?  The Data General raises Constraint_Error on the
>first two but not on the third. 

I tried this on the Verdix compiler, and got the same result as the
Data General.  I dug through the LRM, and found the following passage
which (I think) explains why Verdix and Data General are correct:

LRM 4.3.1 Paragraph 1:
   ... A component association with the choice others ( your case 1 )
   or with more than one choice ( your case 2 ) is only allowed if the
   represented components are all of the same type. ...

The X and Y components of your record are (implicitly) of different
types (as defined by LRM 3.6, paragraphs 14-17, especially 17), 
so your first and second examples are illegal.  Why it gives
a CONSTRAINT_ERROR is not entirely clear to me.  I guess the compiler
picks one of the two string types, and then gets the exception when
it tries to assign it to the other type.

>                                  Is the subaggregate
>	(others => 'a')
>in the first (and second) assignment evaluated once or twice?

The LRM also states (4.3.1 Paragraph 3) "... The expression of a named 
association is evaluated once for each associated component."  They 
give an example of a binary tree node aggregrate:
   ( Value => 0, Succ|Pred => new Cell'(O,null,null) )
and point out that the new operation is executed twice, once for Succ,
and once for Pred.

>Do things change if the components X and Y are of different lengths?

No, I don't think so.  The two components are already of different types,
so the exact indices and length of the strings don't really matter.
I did try the example as follows:

	procedure Agg is
	    type R is
		record
		    X : String (1 .. 2) := (others => 'z');
		    Y : String (1 .. 2) := (others => 'z');
		end record;
	     A : R;
	begin
	    A := (others => (others => 'a'));
	    A := (X | Y => (others => 'a'));
	    A := ((others => 'c'), (others => 'c'));
	end Agg;

This works ok, which I did not expect.  I'm not sure why.  I guess in this
case, the compiler still picks one of the two types, and this time, when 
it assigns it to the component of the other type, it works ok.  I wonder 
if both compilers should have an additional check (at compile time?)
to verify the first sentence quoted above.  That is, should the compiler
explicitly check the types when others or multiple components are used?

By the way, I'm posting this to net.lang.ada on USENET.  Do you folks
on ARPANET see this?

Jon M. Holdman, Shell Development Co.
UUCP: ...{ihnp4, ut-sally, pur-ee}!shell!jon
ARPA: "ihnp4!shell!jon"@Berkeley.ARPA         -- I'm not sure this is right