CVS difference for ai12s/ai12-0127-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0127-1.txt

--- ai12s/ai12-0127-1.txt	2016/06/07 22:05:32	1.4
+++ ai12s/ai12-0127-1.txt	2016/06/08 02:16:07	1.5
@@ -1052,3 +1052,82 @@
 (I didn't make that change in the draft, it needs discussion.)
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, June 7, 2016  5:16 PM
+
+I agree with your points here Randy.  I had the same concerns with some of the
+wording.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 7, 2016  5:40 PM
+
+...
+> The next paragraph doesn't make any sense as written:
+> 
+> The expected type for expression in a delta_aggregate depends on which 
+> form of delta_aggregate_association is used: a record type for 
+> record_component_association_list, and an array type for 
+> array_component_association_list or 
+> multidimensional_array_component_association_list.
+
+It strikes me that there needs to be a Legality Rule that prevents a record
+from having array components and vice versa. But we surely wouldn't want to
+get that tangled into resolution. Resolution is hard enough as it is, and we
+don't want to make it too smart.
+
+The Legality Rule could be:
+
+If the delta_aggregate contains a record_component_association_list, the type
+of the *base_*expression shall be a record type. Similarly, if the
+delta_aggregate contains an array_component_association_list or
+multidimensional_array_component_list, the type of the *base_*expression shall
+be an array type.
+
+Perhaps this could be combined with some of the other Legality Rules.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Tuesday, June 7, 2016  6:03 PM
+
+> >> For an array delta aggregate, the dimensionality of the type of the 
+> >> delta
+> >> >aggregate shall be 1; for a multidimensional delta aggregate the 
+> >> >dimensionality of the type of the delta aggregate shall more than 1.
+> > Here's a place where the above-mentioned ambiguity comes into play.
+> >
+> 
+> I'd say that's the place where the ambiguity is resolved.
+
+No, that's not marked as a Name Resolution rule.  Just Legality.
+So it can't be used to resolve syntactic ambiguities.
+
+> But I agree that your proposed syntax change is an improvement and 
+> with that change there is no ambiguity to even discuss.
+
+OK.
+
+> > I think you want the type to come from context, like other aggregates.
+> > Then that type becomes the expected type for the expression.
+> 
+> Interesting question. Given that we didn't modify 4.3(3/2), I agree 
+> with you. But we could modify that rule.
+> 
+> Do we want to allow
+> 
+>       type T is new String;
+>       procedure P (X : String) is ... ;
+>       procedure P (X : T) is ... ;
+>       Y : String := ... ;
+>    begin
+>       P (X => (Y with delta ...));
+
+No.  Resolution rules should be weak.
+
+> ? Probably not, so 4.3(3/2) is left unmodified and I agree with your 
+> proposed change.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent