CVS difference for ai05s/ai05-0118-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai05s/ai05-0118-1.txt

--- ai05s/ai05-0118-1.txt	2008/10/17 05:26:58	1.1
+++ ai05s/ai05-0118-1.txt	2008/12/02 06:01:19	1.2
@@ -1,7 +1,8 @@
-!standard 6.4(9)                                                08-10-16  AI05-0118-1/01
-!standard 6.4.1(2)
+!standard 6.4.1(2)                                                08-11-17  AI05-0118-1/02
 !standard 12.3(9)
 !class binding interpretation 08-10-16
+!status Amendment 201Z 08-11-26
+!status ARG Approved  8-0-0  08-11-01
 !status work item 08-10-16
 !status received 08-08-06
 !priority Low
@@ -31,35 +32,28 @@
 
 !wording
 
-Add after 6.4(9):
-
-A positional parameter_association corresponds to the formal
-parameter with the same position in the formal part.
-
-AARM To Be Honest: This is after any transformation of prefixed views.
-
-[Editor's Note: Is this good enough, or do we want to try to take prefixed views
-into account here? Note that we didn't change the wording of the rest of this for
-prefixed views.]
-
 Modify 6.4.1(2):
-
-The formal_parameter_selector_name of a parameter_association shall resolve to denote
-a parameter_specification of the view being called{; the parameter_association
-is associated with the denoted formal parameter}.
 
-[One could argue that this entire rule belongs in 6.4, as it is needed to
-understand/enforce 6.4(9). But as Name Resolution Rules are all combined
-anyway, and moving it seems like too much change for a very minor fix.]
+The formal_parameter_selector_name of a {named} parameter_association shall resolve
+to denote a parameter_specification of the view being called{; this is the formal
+parameter of the association. The formal parameter for a positional
+parameter_association is the parameter with the corresponding position in the
+formal part of the view being called}.
+
+AARM To Be Honest: For positional parameters, the "corresponding position" is
+calculated after any transformation of prefixed views.
+
+Modify 12.3(9):
+
+The generic_formal_parameter_selector_name of a {named} generic_association shall
+denote a generic_formal_parameter_declaration of the generic unit being instantiated.
+If two or more formal subprograms have the same defining name, then named associations
+are not allowed for the corresponding actuals.
+
+{The generic_formal_parameter_declaration for a positional generic_association
+is the parameter with the corresponding position in the generic_formal_part of the
+generic unit being instantiated.}
 
-Add after 12.3(9):
-
-A positional generic_association corresponds to the generic_formal_parameter_declaration
-with the same position in the generic_formal_part.
-
-[Editor's note: Have to put this here so that it can be used in the following legality
-rule. We could add it to the start of 12.3(10) instead.]
-
 !discussion
 
 Wording defining the associations was present in the Ada 83 Standard,
@@ -68,21 +62,54 @@
 in the formal part."
 
 This wording was present in early versions of the Ada 9x standard, but
-it disappears in version 3.0. Since it wasn't moved anywhere, was just lost.
+it disappears in version 3.0. Since it wasn't moved anywhere, it was just lost.
+(The author speculates that an attempt to unify all of these uses of positional
+notation was made, but after the attempt failed, some of the wording was not restored.
+But we'll never know.)
 
 It should be noted that there is no clear specification of the association
 for named parameter associations either; 6.4.1(2) only mentions the resolution of the
-parameter name, and does not clearly state that the association associated with
-the denoted formal parameter. We add a few words to make that clear (it would odd
-without them, given the wording for positional notation).
+parameter name, and does not clearly state that the association is associated with
+the denoted formal parameter. We add a few words to make that clear (it would look
+odd without them, given the wording for positional notation).
 
+It makes the most sense to put the needed positional text into 6.4.1(2) so it is
+not widely separated from that for named notation.
+
 It might be thought that the wording for subprogram positional calls needs to take
 into account calls of prefixed views:
      A.Op (B);
 In this call, B associated with the second formal parameter. However, we lean on
 on the equivalence defined in 6.4(10.1/2) and don't change the wording.
+
+!corrigendum 6.4.1(2)
 
---!corrigendum 13.11(16)
+@drepl
+The @i<formal_parameter_>@fa<selector_name> of a @fa<parameter_association>
+shall resolve to denote a @fa<parameter_specification> of the view being called.
+@dby
+The @i<formal_parameter_>@fa<selector_name> of a {named} @fa<parameter_association>
+shall resolve to denote a @fa<parameter_specification> of the view being called{;
+this is the formal parameter of the association. The formal parameter for a positional
+@fa<parameter_association> is the parameter with the corresponding position in the
+formal part of the view being called}.
+
+!corrigendum 12.3(9)
+
+@drepl
+The @i<generic_formal_parameter_>@fa<selector_name> of a @fa<generic_association>
+shall denote a @fa<generic_formal_parameter_declaration> of the generic unit being
+instantiated. If two or more formal subprograms have the same defining name, then
+named associations are not allowed for the corresponding actuals.
+@dby
+The @i<generic_formal_parameter_>@fa<selector_name> of a named @fa<generic_association>
+shall denote a @fa<generic_formal_parameter_declaration> of the generic unit being
+instantiated. If two or more formal subprograms have the same defining name, then
+named associations are not allowed for the corresponding actuals.
+
+The @fa<generic_formal_parameter_declaration> for a positional @fa<generic_association>
+is the parameter with the corresponding position in the @fa<generic_formal_part> of the
+generic unit being instantiated.
 
 
 !ACATS Test

Questions? Ask the ACAA Technical Agent