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

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

--- ai12s/ai12-0127-1.txt	2016/06/07 04:44:28	1.3
+++ ai12s/ai12-0127-1.txt	2016/06/07 22:05:32	1.4
@@ -1,4 +1,4 @@
-!standard A.3.4                                     16-06-06    AI12-0127-1/02
+!standard A.3.4                                     16-06-07    AI12-0127-1/03
 !class Amendment 14-08-21
 !status work item 14-08-21
 !status received 14-07-14
@@ -100,7 +100,7 @@
 
 Syntax
 
-  delta_aggregate ::= (expression with delta delta_aggregate_association)
+  delta_aggregate ::= (*base_*expression with delta delta_aggregate_association)
 
   delta_aggregate_association ::=
     record_component_association_list                 |
@@ -116,12 +116,13 @@
 
   index_tuple_list ::= index_tuple { | index_tuple }
 
-  index_tuple ::= ( expression {, expression} )
+  index_tuple ::= ( expression, expression {, expression} )
 
 Name Resolution Rules
 
-The type of a delta aggregate is the same as the type of the expression in
-delta_aggregate.
+The expected type for a delta_aggregate shall be a single array type, record
+type, or record extension. The expected type for the *base_*expression 
+is the type of the enclosing delta_aggregate.
 
 The expected type for expression in a delta_aggregate depends on which form
 of delta_aggregate_association is used: a record type for
@@ -974,7 +975,80 @@
 aggregate" (the name in the second draft). Issues that can be fixed, but
 probably don't matter if there are major problems with this (not that I see
 any).
+
+****************************************************************
+
+From: Steve Baird
+Sent: Tuesday, June 7, 2016  2:32 AM
+
+>> 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.
+
+But I agree that your proposed syntax change is an improvement and with that
+change there is no ambiguity to even discuss.
+
+> 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 ...));
+
+? Probably not, so 4.3(3/2) is left unmodified and I agree with your proposed change.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, June 7, 2016  5:02 PM
+
+I've applied these two changes into the working draft of the AI (so we don't
+have to waste meeting time discussing them).
+
+I changed the Name Resolution Rule in A.3.4 as follows (copying A.3.2 as
+closely as possible):
+
+   The expected type for a delta_aggregate shall be a single array type, record
+   type, or record extension. The expected type for the *base_*expression 
+   is the type of the enclosing delta_aggregate.
+
+Note that I gave the first expression in the aggregate a prefix so it can't be
+confused with any of the others:
+  delta_aggregate ::= (*base_*expression with delta delta_aggregate_association)
+
+We may want to come up with a better prefix for this.
+
+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.
+
+The *base_*expression's type doesn't depend on that at all, and there is no
+other expression (directly) in the syntax of a delta_aggregate. The way
+expressions in component_associations are interpreted depends on those
+component associations, but that is already defined in 4.3.1 and 4.3.3 (to the
+extent that you reuse those, hopefully a lot).
+
+Indeed, I'd only mention the types for the new kind of association, the
+multidimensional_array_component_association. The others are defined where
+they're declared, repeating wording here is only going to introduce conflicts.
 
-          Randy Brukardt, ARG Editor.
+(I didn't make that change in the draft, it needs discussion.)
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent