Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

6.3.1 Conformance Rules

1
{conformance} [When subprogram profiles are given in more than one place, they are required to conform in one of four ways: type conformance, mode conformance, subtype conformance, or full conformance.] 

Static Semantics

2/1
{8652/0011} {AI95-00117-01} {convention} {calling convention} [As explained in B.1, “Interfacing Pragmas”, a convention can be specified for an entity.] Unless this International Standard states otherwise, the default convention of an entity is Ada. [For a callable entity or access-to-subprogram type, the convention is called the calling convention.] The following conventions are defined by the language:
3
{Ada calling convention} {calling convention (Ada)} The default calling convention for any subprogram not listed below is Ada. [A pragma Convention, Import, or Export may be used to override the default calling convention (see B.1)]. 
3.a
Ramification: See also the rule about renamings-as-body in 8.5.4
4
{Intrinsic calling convention} {calling convention (Intrinsic)} The Intrinsic calling convention represents subprograms that are “built in” to the compiler. The default calling convention is Intrinsic for the following: 
5
an enumeration literal;
6
a "/=" operator declared implicitly due to the declaration of "=" (see 6.6);
7
any other implicitly declared subprogram unless it is a dispatching operation of a tagged type;
8
an inherited subprogram of a generic formal tagged type with unknown discriminants; 
8.a.1/1
Reason: Consider: 
8.a.2/1
package P is
    type Root is tagged null record;
    procedure Proc(X: Root);
end P;
8.a.3/1
generic
    type Formal(<>) is new Root with private;
package G is
    ...
end G;
8.a.4/1
package body G is
    ...
    X: Formal := ...;
    ...
    Proc(X); -- This is a dispatching call in Instance, because
             -- the actual type for Formal is class-wide.
    ...
    -- Proc'Access would be illegal here, because it is of
    -- convention Intrinsic, by the above rule.
end G;
8.a.5/1
type Actual is new Root with ...;
procedure Proc(X: Actual);
package Instance is new G(Formal => Actual'Class);
    -- It is legal to pass in a class-wide actual, because Formal
    -- has unknown discriminants.
8.a.6/1
Within Instance, all calls to Proc will be dispatching calls, so Proc doesn't really exist in machine code, so we wish to avoid taking 'Access of it. This rule applies to those cases where the actual type might be class-wide, and makes these Intrinsic, thus forbidding 'Access. 
9
an attribute that is a subprogram;
10/2
{AI95-00252-01} a subprogram declared immediately within a protected_body;
10.1/2
{AI95-00252-01} {AI95-00407-01} any prefixed view of a subprogram (see 4.1.3).
10.a/2
Reason: The profile of a prefixed view is different than the “real” profile of the subprogram (it doesn't have the first parameter), so we don't want to be able to take 'Access of it, as that would require generating a wrapper of some sort.
11
[The Access attribute is not allowed for Intrinsic subprograms.] 
11.a
Ramification: The Intrinsic calling convention really represents any number of calling conventions at the machine code level; the compiler might have a different instruction sequence for each intrinsic. That's why the Access attribute is disallowed. We do not wish to require the implementation to generate an out of line body for an intrinsic.
11.b
Whenever we wish to disallow the Access attribute in order to ease implementation, we make the subprogram Intrinsic. Several language-defined subprograms have “pragma Convention(Intrinsic, ...);”. An implementation might actually implement this as “pragma Import(Intrinsic, ...);”, if there is really no body, and the implementation of the subprogram is built into the code generator.
11.c
Subprograms declared in protected_bodies will generally have a special calling convention so as to pass along the identification of the current instance of the protected type. The convention is not protected since such local subprograms need not contain any “locking” logic since they are not callable via “external” calls; this rule prevents an access value designating such a subprogram from being passed outside the protected unit.
11.d
The “implicitly declared subprogram” above refers to predefined operators (other than the "=" of a tagged type) and the inherited subprograms of untagged types. 
12
{protected calling convention} {calling convention (protected)} The default calling convention is protected for a protected subprogram, and for an access-to-subprogram type with the reserved word protected in its definition.
13
{entry calling convention} {calling convention (entry)} The default calling convention is entry for an entry.
13.1/2
{AI95-00254-01} {AI95-00409-01} The calling convention for an anonymous access-to-subprogram parameter or anonymous access-to-subprogram result is protected if the reserved word protected appears in its definition and otherwise is the convention of the subprogram that contains the parameter. 
13.a/2
Ramification: The calling convention for other anonymous access-to-subprogram types is Ada. 
13.2/1
{8652/0011} {AI95-00117-01} [If not specified above as Intrinsic, the calling convention for any inherited or overriding dispatching operation of a tagged type is that of the corresponding subprogram of the parent type.] The default calling convention for a new dispatching operation of a tagged type is the convention of the type. 
13.a.1/1
Reason: The first rule is officially stated in 3.9.2. The second is intended to make interfacing to foreign OOP languages easier, by making the default be that the type and operations all have the same convention. 
14
Of these four conventions, only Ada and Intrinsic are allowed as a convention_identifier in a pragma Convention, Import, or Export. 
14.a
Discussion: The names of the protected and entry calling conventions cannot be used in the interfacing pragmas. Note that protected and entry are reserved words.
15/2
{AI95-00409-01} {type conformance} {profile (type conformant)} Two profiles are type conformant if they have the same number of parameters, and both have a result if either does, and corresponding parameter and result types are the same, or, for access parameters or access results, corresponding designated types are the same, or corresponding designated profiles are type conformant. {type profile: See profile, type conformant}
15.a/2
Discussion: {AI95-00409-01} For anonymous access-to-object parameters, the designated types have to be the same for type conformance, not the access types, since in general each access parameter has its own anonymous access type, created when the subprogram is called. Of course, corresponding parameters have to be either both access parameters or both not access parameters.
15.b/2
{AI95-00409-01} Similarly, for anonymous access-to-subprogram parameters, the designated profiles of the types, not the types themselves, have to be conformant.
16/2
{AI95-00318-02} {AI95-00409-01} {mode conformance} {profile (mode conformant)} Two profiles are mode conformant if they are type-conformant, and corresponding parameters have identical modes, and, for access parameters or access result types, the designated subtypes statically match, or the designated profiles are subtype conformant. {statically matching (required) [partial]}
17
{subtype conformance} {profile (subtype conformant)} Two profiles are subtype conformant if they are mode-conformant, corresponding subtypes of the profile statically match, and the associated calling conventions are the same. The profile of a generic formal subprogram is not subtype-conformant with any other profile. {statically matching (required) [partial]}
17.a
Ramification: {generic contract issue [partial]}
18
{full conformance (for profiles)} {profile (fully conformant)} Two profiles are fully conformant if they are subtype-conformant, and corresponding parameters have the same names and have default_expressions that are fully conformant with one another. 
18.a
Ramification: Full conformance requires subtype conformance, which requires the same calling conventions. However, the calling convention of the declaration and body of a subprogram or entry are always the same by definition. 
19
{full conformance (for expressions)} Two expressions are fully conformant if, [after replacing each use of an operator with the equivalent function_call:]
20
each constituent construct of one corresponds to an instance of the same syntactic category in the other, except that an expanded name may correspond to a direct_name (or character_literal) or to a different expanded name in the other; and
21
each direct_name, character_literal, and selector_name that is not part of the prefix of an expanded name in one denotes the same declaration as the corresponding direct_name, character_literal, or selector_name in the other; and 
21.a
Ramification: Note that it doesn't say “respectively” because a direct_name can correspond to a selector_name, and vice-versa, by the previous bullet. This rule allows the prefix of an expanded name to be removed, or replaced with a different prefix that denotes a renaming of the same entity. However, it does not allow a direct_name or selector_name to be replaced with one denoting a distinct renaming (except for direct_names and selector_names in prefixes of expanded names). Note that calls using operator notation are equivalent to calls using prefix notation.
21.b
Given the following declarations: 
21.c
package A is
    function F(X : Integer := 1) return Boolean;
end A;
21.d
with A;
package B is
    package A_View renames A;
    function F_View(X : Integer := 9999) return Boolean renames F;
end B;
21.e
with A, B; use A, B;
procedure Main is ...
21.f
Within Main, the expressions “F”, “A.F”, “B.A_View.F”, and “A_View.F” are all fully conformant with one another. However, “F” and “F_View” are not fully conformant. If they were, it would be bad news, since the two denoted views have different default_expressions.
21.1/1
{8652/0018} {AI95-00175-01} each attribute_designator in one must be the same as the corresponding attribute_designator in the other; and
22
each primary that is a literal in one has the same value as the corresponding literal in the other. 
22.a
Ramification: The literals may be written differently. 
22.b
Ramification: Note that the above definition makes full conformance a transitive relation. 
23
{full conformance (for known_discriminant_parts)} Two known_discriminant_parts are fully conformant if they have the same number of discriminants, and discriminants in the same positions have the same names, statically matching subtypes, and default_expressions that are fully conformant with one another. {statically matching (required) [partial]}
24
{full conformance (for discrete_subtype_definitions)} Two discrete_subtype_definitions are fully conformant if they are both subtype_indications or are both ranges, the subtype_marks (if any) denote the same subtype, and the corresponding simple_expressions of the ranges (if any) fully conform. 
24.a
Ramification: In the subtype_indication case, any ranges have to be corresponding; that is, two subtype_indications cannot conform unless both or neither has a range.
24.b
Discussion: This definition is used in 9.5.2, “Entries and Accept Statements” for the conformance required between the discrete_subtype_definitions of an entry_declaration for a family of entries and the corresponding entry_index_specification of the entry_body.
24.1/2
  {AI95-00345-01} {AI95-00397-01} {prefixed view profile} The prefixed view profile of a subprogram is the profile obtained by omitting the first parameter of that subprogram. There is no prefixed view profile for a parameterless subprogram. For the purposes of defining subtype and mode conformance, the convention of a prefixed view profile is considered to match that of either an entry or a protected operation.
24.c/2
Discussion: This definition is used to define how primitive subprograms of interfaces match operations in task and protected type definitions (see 9.1 and 9.4). 
24.d/2
Reason: The weird rule about conventions is pretty much required for synchronized interfaces to make any sense. There will be wrappers all over the place for interfaces anyway. Of course, this doesn't imply that entries have the same convention as protected operations. 

Implementation Permissions

25
An implementation may declare an operator declared in a language-defined library unit to be intrinsic.

Extensions to Ada 83

25.a
{extensions to Ada 83} The rules for full conformance are relaxed — they are now based on the structure of constructs, rather than the sequence of lexical elements. This implies, for example, that "(X, Y: T)" conforms fully with "(X: T; Y: T)", and "(X: T)" conforms fully with "(X: in T)". 

Wording Changes from Ada 95

25.b/2
{8652/0011} {AI95-00117-01} Corrigendum: Clarified that the default convention is Ada. Also clarified that the convention of a primitive operation of a tagged type is the same as that of the type.
25.c/2
{8652/0018} {AI95-00175-01} Corrigendum: Added wording to ensure that two attributes conform only if they have the same attribute_designator.
25.d/2
{AI95-00252-01} {AI95-00254-01} {AI95-00407-01} Defined the calling convention for anonymous access-to-subprogram types and for prefixed views of subprograms (see 4.1.3).
25.e/2
{AI95-00318-02} Defined the conformance of access result types (see 6.1).
25.f/2
{AI95-00345-01} {AI95-00397-01} Defined the prefixed view profile of subprograms for later use.
25.g/2
{AI95-00409-01} Defined the conformance of anonymous access-to-subprogram parameters.

Contents   Index   References   Search   Previous   Next 
Ada-Europe Sponsored by Ada-Europe