Version 1.4 of ai05s/ai05-0118-1.txt

Unformatted version of ai05s/ai05-0118-1.txt version 1.4
Other versions for file ai05s/ai05-0118-1.txt

!standard 6.4.1(2)          09-05-30 AI05-0118-1/03
!standard 12.3(9)
!class binding interpretation 08-10-16
!status Amendment 201Z 08-11-26
!status WG9 Approved 09-06-12
!status ARG Approved 8-0-0 08-11-01
!status work item 08-10-16
!status received 08-08-06
!priority Low
!difficulty Easy
!qualifier Omission
!subject The association of parameter associations
!summary
Positional associations associate to formals in the order that they are given in the call or instance.
!question
It appears that the Standard does not contain any definition of how positional notation is interpreted in the cases of subprogram calls and generic instantiations.
This is defined in 3.7.1(5) for discriminant constraints, and in 4.3.1(11) and 4.3.3(1) for aggregates. But there does not seem to be any corresponding language in 6.4 or 6.4.1 for subprograms, nor in 12.3 for generic instantiations.
!recommendation
(See Summary.)
!wording
Modify 6.4.1(2):
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.}
!discussion
Wording defining the associations was present in the Ada 83 Standard, in 6.4(3): "For a positional association, the actual parameter corresponds to the formal parameter with the same position 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, 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 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)
Replace the paragraph:
The formal_parameter_selector_name of a parameter_association shall resolve to denote a parameter_specification of the view being called.
by:
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.
!corrigendum 12.3(9)
Replace the paragraph:
The generic_formal_parameter_selector_name of a 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.
by:
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.
!ACATS Test
This has been tested in the ACATS since the dawn of (Ada) time.
!appendix

!topic "Positional notation" not defined
!reference 6.4, 12.3
!from Adam Beneschan 08-08-06
!discussion

This is probably a very minor point.  But it appears to me that the RM does not
contain any definition of how positional notation is interpreted in the cases
of subprogram calls and generic instantiations. 

For discriminant constraints, 3.7.1(5) does define this ("the associated
discriminant is the one whose discriminant_specificaxtion occurred in the
corresponding position...").  Similarly for record aggregates, in 4.3.1(11).

But I can't find any similar language for subprogram calls.  The Ada
83 manual did mention this (RM83 6.4(3): "For a positional association,
the actual parameter corresponds to the formal parameter with the same position
in the formal part").  This language seems to have gotten lost when things got
rearranged for Ada 95.  I can't find anything like it in 6.4, 6.4.1, or anywhere else.

Similarly, I can't find any similar language about positional associations for
actual parameters in generic instantiations.  (The Ada 83 manual handled this
by saying "in the same manner as parameter associations of subprogram calls".)

This may not be a serious problem---everyone seems to know how it works.
It conceivably *could* be a problem for an Ada newcomer who is used to languages
without default parameters; if a subprogram is defined like

    procedure P (A : Type_1 := Some_Default_Expression;
                 B : Type_2);

and the newcomer wants to know if, in a call to P(X), the X is the actual
parameter for "A" or if "A" is skipped because it has a default expression, he's
not going to find the answer in the RM because it isn't there.  That's just
hypothetical, of course.

****************************************************************


Questions? Ask the ACAA Technical Agent