CVS difference for ai12s/ai12-0061-1.txt
--- ai12s/ai12-0061-1.txt 2013/11/13 01:47:00 1.2
+++ ai12s/ai12-0061-1.txt 2014/06/19 04:53:17 1.3
@@ -1,4 +1,4 @@
-!standard 4.3.3(5/2) 13-11-12 AI12-0061-1/02
+!standard 4.3.3(5/2) 14-05-19 AI12-0061-1/03
!standard 4.3.3(23)
!standard 3.1(6/3)
!standard 3.3.1(23/3)
@@ -16,7 +16,7 @@
!problem
When the element type of an array is limited, it is not possible to
-create an aggregate that gives a different value, defined value to each
+create an aggregate that gives a different defined value to each
component.
For instance, to call a function to initialize each element based on
@@ -28,7 +28,7 @@
where Function_Returning_Lim returns a limited type, would provide a
way to create an aggregate that would be difficult to create otherwise.
-Ada 9x team noted this problem in giving different discriminants to
+The Ada 9x team noted this problem in giving different discriminants to
an array of tasks, see the example.
!proposal
@@ -48,57 +48,48 @@
Add after 3.3(18.1/3) (as a bulleted list item):
- The index parameter of a parameterized_array_component_association.
-Add ", parameterized_array_component_association"
-in the comment-separated list of 3.3.1(23/3), immediately after ",
-iterator_specification".
-
- Change 4.3.3(5/2) to:
- array_component_association ::=
- discrete_choice_list => expression
- | discrete_choice_list => <>
- | parameterized_array_component_association
+Add ", iterated_component_association"
+in the comment-separated list of 3.3.1(23/3), immediately
+after ", iterator_specification".
+
+ Change 4.3.3(5/2) to:
+ array_component_association ::=
+ discrete_choice_list => expression
+ | discrete_choice_list => <>
+ | iterated_component_association
- parameterized_array_component_association ::=
- for defining_identifier in discrete_choice_list => expression
+ iterated_component_association ::=
+ for defining_identifier in discrete_choice_list => expression
Add after 4.3.3(6) (at the end of the syntax section):
- The defining_identifier of a parameterized_array_component_association
- declares an index_parameter, an object of the corresponding index
- type.
+ The defining_identifier of an iterated_component_association
+ declares an index_parameter, an object of the corresponding index
+ type.
Append after 4.3.3(20) (at the end of the static semantics section)
- The subtype of an index_parameter is defined as follows:
- - If every discrete_choice in the corresponding discrete_choice_list
- either is a static expressions or is a subtype indication or range
- that defines a static non-null range, then the lowest and
- highest of the values covered by the discrete_choice_list
- are the bounds of the subtype of the index parameter.
- The subtype is constrained and static in this case.
+ The subtype (and nominal subtype) of an index_parameter is the
+ corresponding index subtype.
- - Otherwise the subtype is the corresponding index subtype.
+[We could define a more precise subtype, but the consensus at
+the Pittsburgh meeting was to keep this definition simple.]
- The subtype of an index_parameter is also its nominal subtype.
-
-TBD: define a static predicate for the subtype in the static case? This could
-be useful with case expressions.
-
Add after 4.3.3(31) (at the end of the dynamic semantics section)
[Editor's note: I think this is the wrong place, as it is after checks and bounds text;
-I think it belongs near 4.3.3(23).]
+I think it belongs immediately after 4.3.3(23), in particular 4.3.3(23.1/4) needs to
+apply to evaluating these component expressions or <>s as it does to other kinds.]
- During an evaluation of the expression a parameterized
- array_component_association, the value of the corresponding
- index parameter is that of the corresponding index of the
- corresponding array component.
+ During an evaluation of the expression an iterated_component_association,
+ the value of the corresponding index parameter is that of the
+ corresponding index of the corresponding array component.
AARM Note:
- Taken together with the preceding rule that "The array component
- expressions of the aggregate are evaluated in an arbitrary order",
- this implies that an index parameter can take on its values in an
- arbitrary order. This is different than, for example,
- a loop_parameter.
+ Taken together with the preceding rule that "The array component
+ expressions of the aggregate are evaluated in an arbitrary order",
+ this implies that an index parameter can take on its values in an
+ arbitrary order. This is different than, for example,
+ a loop_parameter.
Add after 4.3.3(32/3): [Editor's note: I moved this, Steve had it in the wrong
place.]
@@ -106,17 +97,19 @@
Note:
An index_parameter is a constant object (see 3.3).
-[The note is intended to follow the example of 5.5(10).]
+[The note is intended to be similar to the note 5.5(10).]
+[Editor's note: Should we add an example after 4.3.3(45) for this new construct?
+It seems likely to be used.]
+
In 5.5(6), replace "whose subtype" with "whose subtype (and nominal subtype)".
[Because the nominal subtype for a loop_parameter was never defined.]
Add after 8.1(4) (as a bulleted list item):
- - A parameterized_array_component_association;
+ - An iterated_component_association;
Add to the list of 13.1.1(4.b/3): (after iterator specification)
- parameterizied_array_comonent_association -- NO
-
+ iterated_component_association -- NO
!discussion
@@ -133,7 +126,7 @@
are allowed. The rule about dynamic named choices still applies, so
either the syntax is a regular for loop, or it can be expanded at compile
-time (as in the above example). So the extra implementation burden of
+time (as in the above example). Thus, the extra implementation burden of
allowing a list should be minimal.
Note that the wording for AI12-0050 handles conformance for this new construct
Questions? Ask the ACAA Technical Agent