AARM95 - The Context of Overload Resolution

[{overload resolution} Because declarations can be overloaded, it is possible for an occurrence of a usage name to have more than one possible interpretation; in most cases, ambiguity is disallowed. This clause describes how the possible interpretations resolve to the actual interpretation.

{overloading rules} Certain rules of the language (the Name Resolution Rules) are considered ``overloading rules''. If a possible interpretation violates an overloading rule, it is assumed not to be the intended interpretation; some other possible interpretation is assumed to be the actual interpretation. On the other hand, violations of non-overloading rules do not affect which interpretation is chosen; instead, they cause the construct to be illegal. To be legal, there usually has to be exactly one acceptable interpretation of a construct that is a ``complete context'', not counting any nested complete contexts.

{grammar (resolution of ambiguity)} The syntax rules of the language and the visibility rules given in 8.3 determine the possible interpretations. Most type checking rules (rules that require a particular type, or a particular class of types, for example) are overloading rules. Various rules for the matching of formal and actual parameters are overloading rules.]

Language Design Principles

The type resolution rules are intended to minimize the need for implicit declarations and preference rules associated with implicit conversion and dispatching operations.

Name Resolution Rules

{complete context} [Overload resolution is applied separately to each complete context, not counting inner complete contexts.] Each of the following constructs is a complete context:

Ramification: A loop_parameter_specification is a declaration, and hence a complete context.

Reason: We would make it the whole pragma, except that certain pragma arguments are allowed to be ambiguous, and ambiguity applies to a complete context.

Ramification: This means that the expression is resolved without looking at the choices.

{interpretation (of a complete context)} {overall interpretation (of a complete context)} An (overall) interpretation of a complete context embodies its meaning, and includes the following information about the constituents of the complete context, not including constituents of inner complete contexts:

Ramification: Syntactic categories is plural here, because there are lots of trivial productions -- an expression might also be all of the following, in this order: identifier, name, primary, factor, term, simple_expression, and relation. Basically, we're trying to capture all the information in the parse tree here, without using compiler-writer's jargon like ``parse tree''.

Ramification: In most cases, a usage name denotes the view declared by the denoted declaration. However, in certain cases, a usage name that denotes a declaration and appears inside the declarative region of that same declaration, denotes the current instance of the declaration. For example, within a task_body, a usage name that denotes the task_type_declaration denotes the object containing the currently executing task, and not the task type declared by the declaration.

Ramification: Unfortunately, we are not confident that the above list is complete. We'll have to live with that.

To be honest: For ``possible'' interpretations, the above information is tentative.

Discussion: A possible interpretation (an input to overload resolution) contains information about what a usage name might denote, but what it actually does denote requires overload resolution to determine. Hence the term ``tentative'' is needed for possible interpretations; otherwise, the definition would be circular.

{possible interpretation} A possible interpretation is one that obeys the syntax rules and the visibility rules. {acceptable interpretation} {resolve (overload resolution)} {interpretation (overload resolution)} An acceptable interpretation is a possible interpretation that obeys the overloading rules[, that is, those rules that specify an expected type or expected profile, or specify how a construct shall resolve or be interpreted.]

To be honest: One rule that falls into this category, but does not use the above-mentioned magic words, is the rule about numbers of parameter associations in a call (see 6.4).

Ramification: The Name Resolution Rules are the ones that appear under the Name Resolution Rules heading. Some Syntax Rules are written in English, instead of BNF. No rule is a Syntax Rule or Name Resolution Rule unless it appears under the appropriate heading.

{interpretation (of a constituent of a complete context)} The interpretation of a constituent of a complete context is determined from the overall interpretation of the complete context as a whole. [Thus, for example, ``interpreted as a function_call,'' means that the construct's interpretation says that it belongs to the syntactic category function_call.]

{denote} [Each occurrence of] a usage name denotes the declaration determined by its interpretation. It also denotes the view declared by its denoted declaration, except in the following cases:

Ramification: As explained below, a pragma argument is allowed to be ambiguous, so it can denote several declarations, and all of the views declared by those declarations.

Reason: This is needed, for example, for references to the Access attribute from within the type_declaration. Also, within a task_body or protected_body, we need to be able to denote the current task or protected object. (For a single_task_declaration or single_protected_declaration, the rule about current instances is not needed.)

To be honest: The current instance of a generic unit is the instance created by whichever generic_instantiation is of interest at any given time.

Ramification: Within a generic_formal_part, a name that denotes the generic_declaration denotes the generic unit, which implies that it is not overloadable.

Ramification: Usually, a usage name denotes only one declaration, and therefore one view and one entity.

{expected type [distributed]} The expected type for a given expression, name, or other construct determines, according to the type resolution rules given below, the types considered for the construct during overload resolution. {type resolution rules} [ The type resolution rules provide support for class-wide programming, universal numeric literals, dispatching operations, and anonymous access types:]

Ramification: Expected types are defined throughout the RM95. The most important definition is that, for a subprogram, the expected type for the actual parameter is the type of the formal parameter.

The type resolution rules are trivial unless either the actual or expected type is universal, class-wide, or of an anonymous access type.

Ramification: This matching rule handles (among other things) cases like the Val attribute, which denotes a function that takes a parameter of type universal_integer.

The last part of the rule, ``or to a universal type that covers~~includes~~ the class'' implies that if the expected type for an expression is universal_fixed, then an expression whose type is universal_real (such as a real literal) is OK.

Ramification: {Beaujolais effect [partial]} This rule is not intended to create a preference for the specific type -- such a preference would cause Beaujolais effects.

Ramification: This will only be legal as part of a call on a dispatching operation; see 3.9.2, ``Dispatching Operations of Tagged Types''. Note that that rule is not a Name Resolution Rule.

Ramification: Because it says ``access-to-variable'' instead of ``access-to-object,'' two subprograms that differ only in that one has a parameter of an access-to-constant type, and the other has an access parameter, are distinguishable during overload resolution.

The case where the actual is access-to-D'Class will only be legal as part of a call on a dispatching operation; see 3.9.2, ``Dispatching Operations of Tagged Types''. Note that that rule is not a Name Resolution Rule.

{expected profile [distributed]} In certain contexts, [such as in a subprogram_renaming_declaration,] the Name Resolution Rules define an expected profile for a given name; {profile resolution rule (name with a given expected profile)} in such cases, the name shall resolve to the name of a callable entity whose profile is type conformant with the expected profile. {type conformance (required)}

Ramification: The parameter and result subtypes are not used in overload resolution. Only type conformance of profiles is considered during overload resolution. Legality rules generally require at least mode-conformance in addition, but those rules are not used in overload resolution.

Legality Rules

{single (class expected type)} When the expected type for a construct is required to be a single type in a given class, the type expected for the construct shall be determinable solely from the context in which the construct appears, excluding the construct itself, but using the requirement that it be in the given class; the type of the construct is then this single expected type. Furthermore, the context shall not be one that expects any type in some class that contains types of the given class; in particular, the construct shall not be the operand of a type_conversion.

Ramification: For example, the expected type for the literal null is required to be a single access type. But the expected type for the operand of a type_conversion is any type. Therefore, the literal null is not allowed as the operand of a type_conversion. This is true even if there is only one access type in scope. The reason for these rules is so that the compiler will not have to search ``everywhere'' to see if there is exactly one type in a class in scope.

Ramification: This, and the rule below about ambiguity, are the ones that suck in all the Syntax Rules and Name Resolution Rules as compile-time rules. Note that this and the ambiguity rule have to be Legality Rules.

{preference (for root numeric operators and ranges)} There is a preference for the primitive operators (and ranges) of the root numeric types root_integer and root_real. In particular, if two acceptable interpretations of a constituent of a complete context differ only in that one is for a primitive operator (or range) of the type root_integer or root_real, and the other is not, the interpretation using the primitive operator (or range) of the root numeric type is preferred.

Reason: The reason for this preference is so that expressions involving literals and named numbers can be unambiguous. For example, without the preference rule, the following would be ambiguous:

For a complete context, if there is exactly one overall acceptable interpretation where each constituent's interpretation is the same as or preferred (in the above sense) over those in all other overall acceptable interpretations, then that one overall acceptable interpretation is chosen. {ambiguous} Otherwise, the complete context is ambiguous.

A complete context that is a pragma_argument_association is allowed to be ambiguous (unless otherwise specified for the particular pragma), but only if every acceptable interpretation of the pragma argument is as a name that statically denotes a callable entity. {denote (name used as a pragma argument) [partial]} Such a name denotes all of the declarations determined by its interpretations, and all of the views declared by these declarations.

Ramification: This applies to Inline, Suppress, Import, Export, and Convention pragmas. For example, it is OK to say ``pragma Suppress(Elaboration_Check, On => P.Q);'', even if there are two directly visible P's, and there are two Q's declared in the visible part of each P. In this case, P.Q denotes four different declarations. This rule also applies to certain pragmas defined in the Specialized Needs Annexes. It almost applies to Pure, Elaborate_Body, and Elaborate_All pragmas, but those can't have overloading for other reasons.

Note that if a pragma argument denotes a call to a callable entity, rather than the entity itself, this exception does not apply, and ambiguity is disallowed.

Note that we need to carefully define which pragma-related rules are Name Resolution Rules, so that, for example, a pragma Inline does not pick up subprograms declared in enclosing declarative regions, and therefore make itself illegal.

We say ``statically denotes'' in the above rule in order to avoid having to worry about how many times the name is evaluated, in case it denotes more than one callable entity.

16 If a usage name has only one acceptable interpretation, then it denotes the corresponding entity. However, this does not mean that the usage name is necessarily legal since other requirements exist which are not considered for overload resolution; for example, the fact that an expression is static, whether an object is constant, mode and subtype conformance rules, freezing rules, order of elaboration, and so on.

Similarly, subtypes are not considered for overload resolution (the violation of a constraint does not make a program illegal but raises an exception during program execution).

Incompatibilities With Ada 83

{incompatibilities with Ada 83} {Beaujolais effect [partial]} The new preference rule for operators of root numeric types is upward incompatible, but only in cases that involved Beaujolais effects in Ada 83. Such cases are ambiguous in Ada 95.

Extensions to Ada 83

{extensions to Ada 83} The rule that allows an expected type to match an actual expression of a universal type, in combination with the new preference rule for operators of root numeric types, subsumes the Ada 83 "implicit conversion" rules for universal types.

Wording Changes from Ada 83

In Ada 83, it is not clear what the ``syntax rules'' are. AI83-00157 states that a certain textual rule is a syntax rule, but it's still not clear how one tells in general which textual rules are syntax rules. We have solved the problem by stating exactly which rules are syntax rules -- the ones that appear under the ``Syntax'' heading.

RM83 has a long list of the ``forms'' of rules that are to be used in overload resolution (in addition to the syntax rules). It is not clear exactly which rules fall under each form. We have solved the problem by explicitly marking all rules that are used in overload resolution. Thus, the list of kinds of rules is unnecessary. It is replaced with some introductory (intentionally vague) text explaining the basic idea of what sorts of rules are overloading rules.

It is not clear from RM83 what information is embodied in a ``meaning'' or an ``interpretation.'' ``Meaning'' and ``interpretation'' were intended to be synonymous; we now use the latter only in defining the rules about overload resolution. ``Meaning'' is used only informally. This clause attempts to clarify what is meant by ``interpretation.''

For example, RM83 does not make it clear that overload resolution is required in order to match subprogram_bodies with their corresponding declarations (and even to tell whether a given subprogram_body is the completion of a previous declaration). Clearly, the information needed to do this is part of the ``interpretation'' of a subprogram_body. The resolution of such things is defined in terms of the ``expected profile'' concept. Ada 95 has some new cases where expected profiles are needed -- the resolution of P'Access, where P might denote a subprogram, is an example.

RM83-8.7(2) might seem to imply that an interpretation embodies information about what is denoted by each usage name, but not information about which syntactic category each construct belongs to. However, it seems necessary to include such information, since the Ada grammar is highly ambiguous. For example, X(Y) might be a function_call or an indexed_component, and no context-free/syntactic information can tell the difference. It seems like we should view X(Y) as being, for example, ``interpreted as a function_call'' (if that's what overload resolution decides it is). Note that there are examples where the denotation of each usage name does not imply the syntactic category. However, even if that were not true, it seems that intuitively, the interpretation includes that information. Here's an example:

type T; type A is access T; type T is array(Integer range 1..10) of A; I : Integer := 3; function F(X : Integer := 7) return A; Y : A := F(I); -- Ambiguous? (We hope so.)

Consider the declaration of Y (a complete context). In the above example, overload resolution can easily determine the declaration, and therefore the entity, denoted by Y, A, F, and I. However, given all of that information, we still don't know whether F(I) is a function_call or an indexed_component whose prefix~~prefix~~ is a function_call. (In the latter case, it is equivalent to F(7).all(I).)

It seems clear that the declaration of Y ought to be considered ambiguous. We describe that by saying that there are two interpretations, one as a function_call, and one as an indexed_component. These interpretations are both acceptable to the overloading rules. Therefore, the complete context is ambiguous, and therefore illegal.

{Beaujolais effect [partial]} It is the intent that the Ada 95 preference rule for root numeric operators is more locally enforceable than that of RM83-4.6(15). It should also eliminate interpretation shifts due to the addition or removal of a use_clause (the so called Beaujolais effect).

RM83-8.7 seems to be missing some complete contexts, such as pragma_argument_associations, declarative_items that are not declarations or representation_clauses, and context_items. We have added these, and also replaced the ``must be determinable'' wording of RM83-5.4(3) with the notion that the expression of a case_statement is a complete context.