1

[{*precedence of operators*}
{*operator precedence*}
The language defines the following six categories
of operators (given in order of increasing precedence). The corresponding
operator_symbols, and only those, can be used
as designators in declarations of functions
for user-defined operators. See 6.6, “Overloading
of Operators”.]

2

3

4

5

6

7

7.a

8

For a sequence of operators of the same precedence
level, the operators are associated with their operands in textual order
from left to right. Parentheses can be used to impose specific associations.

8.a

8.b

See the Implementation Permissions below regarding
flexibility in reassociating operators of the same precedence.

9

{*predefined operator*}
{*operator (predefined)*}
For each form of type definition, certain of the
above operators are *predefined*; that is, they are implicitly declared
immediately after the type definition. {*binary
operator*} {*operator
(binary)*} {*unary
operator*} {*operator
(unary)*} For each such implicit operator
declaration, the parameters are called Left and Right for *binary*
operators; the single parameter is called Right for *unary* operators.
[An expression of the form X op Y, where op is a binary operator, is
equivalent to a function_call of the form
"op"(X, Y). An expression of the form op Y, where op is a unary
operator, is equivalent to a function_call
of the form "op"(Y). The predefined operators and their effects
are described in subclauses 4.5.1 through
4.5.6.]

10

[{*Constraint_Error
(raised by failure of run-time check)*} The
predefined operations on integer types either yield the mathematically
correct result or raise the exception Constraint_Error. For implementations
that support the Numerics Annex, the predefined operations on real types
yield results whose accuracy is defined in Annex
G, or raise the exception Constraint_Error. ]

10.a

11

{*Constraint_Error
(raised by failure of run-time check)*} The
implementation of a predefined operator that delivers a result of an
integer or fixed point type may raise Constraint_Error only if the result
is outside the base range of the result type.

12

{*Constraint_Error
(raised by failure of run-time check)*} The
implementation of a predefined operator that delivers a result of a floating
point type may raise Constraint_Error only if the result is outside the
safe range of the result type.

12.a

13

For a sequence of predefined operators of the same
precedence level (and in the absence of parentheses imposing a specific
association), an implementation may impose any association of the operators
with operands so long as the result produced is an allowed result for
the left-to-right association, but ignoring the potential for failure
of language-defined checks in either the left-to-right or chosen order
of association.

13.a

13.b

Note that this permission does not apply to
user-defined operators.

NOTES

14

11 The two operands of an expression of
the form X op Y, where op is a binary operator, are evaluated in an arbitrary
order, as for any function_call (see 6.4).

15

16

X > 4.0

17

-4.0*A**2 --* same as –(4.0 * (A**2))*

**abs**(1 + A) + B --* same as (abs (1 + A)) + B*

Y**(-3) --* parentheses are necessary*

A / B * C --* same as (A/B)*C*

A + (B + C) --* evaluate B + C before adding it to A *

Y**(-3) --

A / B * C --

A + (B + C) --

17.a

We don't give a detailed definition of precedence,
since it is all implicit in the syntax rules anyway.

17.b

The permission to reassociate is moved here
from RM83-11.6(5), so it is closer to the rules defining operator association.

Sponsored by **Ada-Europe**