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)}
expression ::=
relation {and relation} | relation {and then relation}
| relation {or relation} | relation {or else relation}
| relation {xor relation}
relation ::=
simple_expression [relational_operator simple_expression]
| simple_expression [not] in range
| simple_expression [not] in subtype_mark
simple_expression ::= [unary_adding_operator] term {binary_adding_operator term}
term ::= factor {multiplying_operator factor}
factor ::= primary [** primary] | abs primary | not primary
primary ::=
numeric_literal | null | string_literal | aggregate
| name | qualified_expression | allocator | (expression)
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.
9 Each expression has a type; it specifies the computation or retrieval of a value of that type.
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.
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.
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
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)
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.