Contents Index 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}
{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
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
- a subprogram declared immediately within a protected_body.
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/1
- {8652/0011} [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
{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, corresponding designated types are the same.
{type
profile: See profile, type conformant}
15.a
Discussion: For access
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.
16
{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, the designated subtypes statically match.
{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} 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.
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)".
Contents Index Previous Next Legal