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/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
{
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.
Sponsored by Ada-Europe