4.4 Expressions
1/3
Syntax
2
2.1/3
2.2/3
3/3
3.1/3
3.2/3
4
5
6
7/3
Name Resolution Rules
8
A
name
used as a
primary
shall resolve to denote an object or a value.
8.a
Discussion: This replaces RM83-4.4(3).
We don't need to mention named numbers explicitly, because the name of
a named number denotes a value. We don't need to mention attributes explicitly,
because attributes now denote (rather than yield) values in general.
Also, the new wording allows attributes that denote objects, which should
always have been allowed (in case the implementation chose to have such
a thing).
8.b
Reason: It might seem odd that this is
an overload resolution rule, but it is relevant during overload resolution.
For example, it helps ensure that a
primary
that consists of only the identifier of a parameterless function is interpreted
as a
function_call
rather than directly as a
direct_name.
Static Semantics
9
Each expression has a type; it specifies the computation
or retrieval of a value of that type.
Dynamic Semantics
10
The value of a
primary
that is a
name
denoting an object is the value of the object.
Implementation Permissions
11
For
the evaluation of a
primary
that is a
name
denoting an object of an unconstrained numeric subtype, if the value
of the object is outside the base range of its type, the implementation
may either raise Constraint_Error or return the value of the object.
11.a
Ramification: This means that if extra-range
intermediates are used to hold the value of an object of an unconstrained
numeric subtype, a Constraint_Error can be raised on a read of the object,
rather than only on an assignment to it. Similarly, it means that computing
the value of an object of such a subtype can be deferred until the first
read of the object (presuming no side-effects other than failing an Overflow_Check
are possible). This permission is over and above that provided by clause
11.6, since this allows the Constraint_Error
to move to a different handler.
11.b
Reason: This permission is intended to
allow extra-range registers to be used efficiently to hold parameters
and local variables, even if they might need to be transferred into smaller
registers for performing certain predefined operations.
11.c
Discussion: There is no need to mention
other kinds of
primarys,
since any Constraint_Error to be raised can be “charged”
to the evaluation of the particular kind of
primary.
Examples
12
Examples of primaries:
13
4.0 -- real literal
Pi -- named number
(1 .. 10 => 0) -- array aggregate
Sum -- variable
Integer'Last -- attribute
Sine(X) -- function call
Color'(Blue) -- qualified expression
Real(M*N) -- conversion
(Line_Count + 10) -- parenthesized expression
14
Examples of expressions:
15/2
{
AI95-00433-01}
Volume --
primary
not Destroyed --
factor
2*Line_Count --
term
-4.0 --
simple expression
-4.0 + A --
simple expression
B**2 - 4.0*A*C --
simple expression
R*Sin(θ)*Cos(φ) -- simple expression
Password(1 .. 3) = "Bwv" --
relation
Count
in Small_Int --
relation
Count
not in Small_Int --
relation
Index = 0
or Item_Hit --
expression
(Cold
and Sunny)
or Warm --
expression (parentheses are required)
A**(B**C) --
expression (parentheses are required)
Extensions to Ada 83
15.a
In Ada 83,
out parameters
and their nondiscriminant subcomponents are not allowed as
primaries.
These restrictions are eliminated in Ada 95.
15.b
In various contexts throughout the language
where Ada 83 syntax rules had
simple_expression,
the corresponding Ada 95 syntax rule has
expression
instead. This reflects the inclusion of modular integer types, which
makes the logical operators "
and", "
or",
and "
xor" more useful in expressions of an integer type.
Requiring parentheses to use these operators in such contexts seemed
unnecessary and potentially confusing. Note that the bounds of a
range
still have to be specified by
simple_expressions,
since otherwise
expressions
involving membership tests might be ambiguous. Essentially, the operation
".." is of higher precedence than the logical operators, and
hence uses of logical operators still have to be parenthesized when used
in a bound of a range.
Wording Changes from Ada 2005
15.c/3
15.d/3
15.e/3
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe