!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 !difficulty Easy !qualifier Omission !subject How do parameter associations associate? !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) @drepl The @i@fa of a @fa shall resolve to denote a @fa of the view being called. @dby The @i@fa of a {named} @fa shall resolve to denote a @fa of the view being called{; this is the formal parameter of the association. The formal parameter for a positional @fa is the parameter with the corresponding position in the formal part of the view being called}. !corrigendum 12.3(9) @drepl The @i@fa of a @fa shall denote a @fa 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@fa of a named @fa shall denote a @fa 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 for a positional @fa is the parameter with the corresponding position in the @fa 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. ****************************************************************