Contents Index Previous Next
4.4 Expressions
1
{expression} An
expression is a formula that defines the computation or retrieval
of a value. In this International Standard, the term ``expression'' refers
to a construct of the syntactic category
expression
or of any of the other five syntactic categories defined below.
{and
operator} {operator (and)}
{or operator} {operator
(or)} {xor operator}
{operator (xor)} {and
then (short-circuit control form)} {or
else (short-circuit control form)} {=
operator} {operator (=)}
{equal operator} {operator
(equal)} {/= operator}
{operator (/=)} {not
equal operator} {operator
(not equal)} {< operator}
{operator (<)} {less
than operator} {operator
(less than)} {<= operator}
{operator (<=)} {less
than or equal operator} {operator
(less than or equal)} {>
operator} {operator (>)}
{greater than operator}
{operator (greater than)}
{>= operator} {operator
(>=)} {greater than
or equal operator} {operator
(greater than or equal)} {in
(membership test)} {not
in (membership test)} {+
operator} {operator (+)}
{plus operator} {operator
(plus)} {- operator}
{operator (-)} {minus
operator} {operator (minus)}
{& operator} {operator
(&)} {ampersand operator}
{operator (ampersand)}
{concatenation operator}
{operator (concatenation)}
{catenation operator: See concatenation
operator} {* operator}
{operator (*)} {multiply
operator} {operator (multiply)}
{times operator} {operator
(times)} {/ operator}
{operator (/)} {divide
operator} {operator (divide)}
{mod operator} {operator
(mod)} {rem operator}
{operator (rem)} {**
operator} {operator (**)}
{exponentiation operator}
{operator (exponentiation)}
{abs operator} {operator
(abs)} {absolute value}
{not operator} {operator
(not)}
Syntax
2
expression
::=
relation {
and relation} |
relation {
and then relation}
|
relation {
or relation} |
relation {
or else relation}
|
relation {
xor relation}
3
relation
::=
simple_expression [
relational_operator simple_expression]
|
simple_expression [
not]
in range
|
simple_expression [
not]
in subtype_mark
4
simple_expression
::= [
unary_adding_operator]
term {
binary_adding_operator term}
5
term
::= factor {
multiplying_operator factor}
6
factor
::= primary [**
primary] |
abs primary |
not primary
7
primary
::=
numeric_literal |
null |
string_literal |
aggregate
|
name |
qualified_expression |
allocator | (
expression)
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
{evaluation (primary that is
a name) [partial]} The value of a
primary
that is a
name denoting an object
is the value of the object.
Implementation Permissions
11
{Overflow_Check [partial]}
{check, language-defined (Overflow_Check)}
{Constraint_Error (raised by failure
of run-time check)} 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
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
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
{extensions to Ada 83}
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.
Contents Index Previous Next Legal