Annotated Ada Reference ManualLegal Information
Table of Contents   Index   References   Search   Previous   Next 

 4.9 Static Expressions and Static Subtypes

Certain expressions of a scalar or string type are defined to be static. Similarly, certain discrete ranges are defined to be static, and certain scalar and string subtypes are defined to be static subtypes. [{static} Static means determinable at compile time, using the declared properties or values of the program entities.] {constant: See also static}
Discussion: As opposed to more elaborate data flow analysis, etc. 

Language Design Principles

For an expression to be static, it has to be calculable at compile time.
Only scalar and string expressions are static.
To be static, an expression cannot have any nonscalar, nonstring subexpressions (though it can have nonscalar constituent names). A static scalar expression cannot have any nonscalar subexpressions. There is one exception — a membership test for a string subtype can be static, and the result is scalar, even though a subexpression is nonscalar.
The rules for evaluating static expressions are designed to maximize portability of static calculations. 
{static (expression)} A static expression is [a scalar or string expression that is] one of the following:
Ramification: A numeric_literal is always a static expression, even if its expected type is not that of a static subtype. However, if its value is explicitly converted to, or qualified by, a nonstatic subtype, the resulting expression is nonstatic.
Ramification: That is, the constrained subtype defined by the index range of the string is static. Note that elementary values don't generally have subtypes, while composite values do (since the bounds or discriminants are inherent in the value). 
Ramification: Note that enumeration literals are covered by the function_call case. 
Ramification: This includes uses of operators that are equivalent to function_calls. 
Ramification: Note that this does not include the case of an attribute that is a function; a reference to such an attribute is not even an expression. See above for function calls.
An implementation may define the staticness and other properties of implementation-defined attributes. 
Ramification: This rules out the subtype_mark'aggregate case. 
Reason: Adding qualification to an expression shouldn't make it nonstatic, even for strings. 
Reason: Clearly, we should allow membership tests in exactly the same cases where we allow qualified_expressions.
Discussion: {static (value)} Informally, we talk about a static value. When we do, we mean a value specified by a static expression. 
Ramification: The language requires a static expression in a number_declaration, a numeric type definition, a discrete_choice (sometimes), certain representation items, an attribute_designator, and when specifying the value of a discriminant governing a variant_part in a record_aggregate or extension_aggregate.
{statically (denote)} A name statically denotes an entity if it denotes the entity and: 
Ramification: Selected_components that are not expanded names and indexed_components do not statically denote things. 
{static (function)} A static function is one of the following: 
Ramification: These are the functions whose calls can be static expressions. 
In any case, a generic formal subprogram is not a static function.
{static (constant)} A static constant is a constant view declared by a full constant declaration or an object_renaming_declaration with a static nominal subtype, having a value defined by a static scalar expression or by a static string expression whose value has a length not exceeding the maximum length of a string_literal in the implementation. 
Ramification: A deferred constant is not static; the view introduced by the corresponding full constant declaration can be static. 
Reason: The reason for restricting the length of static string constants is so that compilers don't have to store giant strings in their symbol tables. Since most string constants will be initialized from string_literals, the length limit seems pretty natural. The reason for avoiding nonstring types is also to save symbol table space. We're trying to keep it cheap and simple (from the implementer's viewpoint), while still allowing, for example, the link name of a pragma Import to contain a concatenation.
The length we're talking about is the maximum number of characters in the value represented by a string_literal, not the number of characters in the source representation; the quotes don't count.
{static (range)} A static range is a range whose bounds are static expressions, [or a range_attribute_reference that is equivalent to such a range.] {static (discrete_range)} A static discrete_range is one that is a static range or is a subtype_indication that defines a static scalar subtype. The base range of a scalar type is a static range, unless the type is a descendant of a formal scalar type.
 {AI95-00263-01} {static (subtype)} A static subtype is either a static scalar subtype or a static string subtype. {static (scalar subtype)} A static scalar subtype is an unconstrained scalar subtype whose type is not a descendant of a formal scalar type, or a constrained scalar subtype formed by imposing a compatible static constraint on a static scalar subtype. {static (string subtype)} A static string subtype is an unconstrained string subtype whose index subtype and component subtype are static (and whose type is not a descendant of a formal array type), or a constrained string subtype formed by imposing a compatible static constraint on a static string subtype. In any case, the subtype of a generic formal object of mode in out, and the result subtype of a generic formal function, are not static.
Ramification: String subtypes are the only composite subtypes that can be static. 
Reason: The part about generic formal objects of mode in out is necessary because the subtype of the formal is not required to have anything to do with the subtype of the actual. For example: 
subtype Int10 is Integer range 1..10;
    F : in out Int10;
procedure G;
procedure G is
    case F is
        when 1..10 => null;
        -- Illegal!
    end case;
end G;
X : Integer range 1..20;
procedure I is new G(F => X); -- OK.
The case_statement is illegal, because the subtype of F is not static, so the choices have to cover all values of Integer, not just those in the range 1..10. A similar issue arises for generic formal functions, now that function calls are object names. 
{static (constraint)} The different kinds of static constraint are defined as follows: 
   {AI95-00311-01} In any case, the constraint of the first subtype of a scalar formal type is neither static nor null.
{statically (constrained)} A subtype is statically constrained if it is constrained, and its constraint is static. An object is statically constrained if its nominal subtype is statically constrained, or if it is a static string constant. 

Legality Rules

A static expression is evaluated at compile time except when it is part of the right operand of a static short-circuit control form whose value is determined by its left operand. This evaluation is performed exactly, without performing Overflow_Checks. For a static expression that is evaluated: 
Ramification: {AI95-00269-01} If the expression is expected to be of a universal type, or of “any integer type”, there are no limits on the value of the expression. 
Ramification: This means that a numeric_literal for a decimal type cannot have “extra” significant digits.
Reason: {AI95-00269-01} The small is not known for a generic formal type, so we have to exclude formal types from this check. 
 {AI95-00269-01} {generic contract issue [partial]} In addition to the places where Legality Rules normally apply (see 12.3), the above restrictions also apply in the private part of an instance of a generic unit. The last two restrictions above do not apply if the expected type is a descendant of a formal scalar type (or a corresponding actual type in an instance).
Discussion: Values outside the base range are not permitted when crossing from the “static” domain to the “dynamic” domain. This rule is designed to enhance portability of programs containing static expressions. Note that this rule applies to the exact value, not the value after any rounding or truncation. (See below for the rounding and truncation requirements.)
Short-circuit control forms are a special case: 
N: constant := 0.0;
X: constant Boolean := (N = 0.0) or else (1.0/N > 0.5); -- Static.
The declaration of X is legal, since the divide-by-zero part of the expression is not evaluated. X is a static constant equal to True.
This paragraph was deleted.Ramification: {AI95-00269-01} There is no requirement to recheck these rules in an instance; the base range check will generally be performed at run time anyway. 

Implementation Requirements

 {AI95-00268-01} {AI95-00269-01} For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal scalar type, the implementation shall round or truncate the value (according to the Machine_Rounds attribute of the expected type) to the nearest machine number of the expected type; if the value is exactly half-way between two machine numbers, the any rounding shall be performed is implementation-defined away from zero. If the expected type is a descendant of a formal scalar type, or if the static expression appears in the body of an instance of a generic unit and the corresponding expression is nonstatic in the corresponding generic body, then no special rounding or truncating is required — normal accuracy rules apply (see Annex G). 
Implementation defined: Rounding of real static expressions which are exactly half-way between two machine numbers.
Reason: {AI95-00268-01} Discarding extended precision enhances portability by ensuring that the value of a static constant of a real type is always a machine number of the type. Deterministic rounding of exact halves also enhances portability.
When the expected type is a descendant of a formal floating point type, extended precision (beyond that of the machine numbers) can be retained when evaluating a static expression, to ease code sharing for generic instantiations. For similar reasons, normal (nondeterministic) rounding or truncating rules apply for descendants of a formal fixed point type.
{AI95-00269-01} There is no requirement for exact evaluation or special rounding in an instance body (unless the expression is static in the generic body). This eliminates a potential contract issue where the exact value of a static expression depends on the actual parameters (which could then affect the legality of other code). 
Implementation Note: Note that the implementation of static expressions has to keep track of plus and minus zero for a type whose Signed_Zeros attribute is True.
{AI95-00100-01} Note that the only machine numbers values of a fixed point type are the multiples of the small, so a static conversion to a fixed-point type, or division by an integer, must do truncation to a multiple of small. It is not correct for the implementation to do all static calculations in infinite precision.

Implementation Advice

   {AI95-00268-01} For a real static expression that is not part of a larger static expression, and whose expected type is not a descendant of a formal type, the rounding should be the same as the default rounding for the target system. 
Implementation Advice: For a real static expression with a non-formal type that is not part of a larger static expression should be rounded the same as the target system.
28  An expression can be static even if it occurs in a context where staticness is not required. 
Ramification: For example: 
X : Float := Float'(1.0E+400) + 1.0 - Float'(1.0E+400);
The expression is static, which means that the value of X must be exactly 1.0, independent of the accuracy or range of the run-time floating point implementation.
The following kinds of expressions are never static: explicit_dereference, indexed_component, slice, null, aggregate, allocator
29  A static (or run-time) type_conversion from a real type to an integer type performs rounding. If the operand value is exactly half-way between two integers, the rounding is performed away from zero. 
Reason: We specify this for portability. The reason for not choosing round-to-nearest-even, for example, is that this method is easier to undo. 
Ramification: The attribute Truncation (see A.5.3) can be used to perform a (static) truncation prior to conversion, to prevent rounding. 
Implementation Note: The value of the literal 0E999999999999999999999999999999999999999999999 is zero. The implementation must take care to evaluate such literals properly.


Examples of static expressions: 
1 + 1       -- 2
abs(-10)*3  -- 30
Kilo : constant := 1000;
Mega : constant := Kilo*Kilo;   -- 1_000_000
Long : constant := Float'Digits*2;
Half_Pi    : constant := Pi/2;           -- see 3.3.2
Deg_To_Rad : constant := Half_Pi/90;
Rad_To_Deg : constant := 1.0/Deg_To_Rad; -- equivalent to 1.0/((3.14159_26536/2)/90)

Extensions to Ada 83

{extensions to Ada 83} The rules for static expressions and static subtypes are generalized to allow more kinds of compile-time-known expressions to be used where compile-time-known values are required, as follows: 
The rules for the evaluation of static expressions are revised to require exact evaluation at compile time, and force a machine number result when crossing from the static realm to the dynamic realm, to enhance portability and predictability. Exact evaluation is not required for descendants of a formal scalar type, to simplify generic code sharing and to avoid generic contract model problems.
Static expressions are legal even if an intermediate in the expression goes outside the base range of the type. Therefore, the following will succeed in Ada 95, whereas it might raise an exception in Ada 83: 
type Short_Int is range -32_768 .. 32_767;
I : Short_Int := -32_768;
This might raise an exception in Ada 83 because "32_768" is out of range, even though "–32_768" is not. In Ada 95, this will always succeed.
Certain expressions involving string operations (in particular concatenation and membership tests) are considered static in Ada 95.
The reason for this change is to simplify the rule requiring compile-time-known string expressions as the link name in an interfacing pragma, and to simplify the preelaborability rules.

Incompatibilities With Ada 83

{incompatibilities with Ada 83} An Ada 83 program that uses an out-of-range static value is illegal in Ada 95, unless the expression is part of a larger static expression, or the expression is not evaluated due to being on the right-hand side of a short-circuit control form. 

Wording Changes from Ada 83

This clause (and 4.5.5, “Multiplying Operators”) subsumes the RM83 section on Universal Expressions.
The existence of static string expressions necessitated changing the definition of static subtype to include string subtypes. Most occurrences of "static subtype" have been changed to "static scalar subtype", in order to preserve the effect of the Ada 83 rules. This has the added benefit of clarifying the difference between "static subtype" and "statically constrained subtype", which has been a source of confusion. In cases where we allow static string subtypes, we explicitly use phrases like "static string subtype" or "static (scalar or string) subtype", in order to clarify the meaning for those who have gotten used to the Ada 83 terminology.
In Ada 83, an expression was considered nonstatic if it raised an exception. Thus, for example: 
Bad: constant := 1/0; -- Illegal!
was illegal because 1/0 was not static. In Ada 95, the above example is still illegal, but for a different reason: 1/0 is static, but there's a separate rule forbidding the exception raising.

Inconsistencies With Ada 95

{AI95-00268-01} {inconsistencies with Ada 95} Amendment Correction: Rounding of static real expressions is implementation-defined in Ada 2005, while it was specified as away from zero in (original) Ada 95. This could make subtle differences in programs. However, the original Ada 95 rule required rounding that (probably) differed from the target processor, thus creating anomalies where the value of a static expression was required to be different than the same expression evaluated at run-time.

Wording Changes from Ada 95

{AI95-00263-01} {AI95-00268-01} The Ada 95 wording that defined static subtypes unintentionally failed to exclude formal derived types that happen to be scalar (these aren't formal scalar types); and had a parenthetical remark excluding formal string types - but that was neither necessary nor parenthetical (it didn't follow from other wording). This issue also applies to the rounding rules for real static expressions.
{AI95-00269-01} Ada 95 didn't clearly define the bounds of a value of a static expression for universal types and for "any integer/float/fixed type". We also make it clear that we do not intend exact evaluation of static expressions in an instance body if the expressions aren't static in the generic body.
{AI95-00311-01} We clarify that the first subtype of a scalar formal type has a nonstatic, non-null constraint. 

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