!topic LSN on Static Expressions in Ada 9X
!key LSN-1039 on Static Expressions in Ada 9X
!reference MS-4.9;4.6
!reference RM83-4.9
!reference AI-00128/04
!from Bob Duff $Date: 92/10/08 18:37:20 $ $Revision: 1.1 $
!discussion

This Language Study Note discusses static expressions in Ada 9X.

The Ada 83 RM does not make it clear whether or not basic operations,
such as 'in' and 'and then', are allowed in static expressions.
AI-00128/04, a binding interpretation, disallows basic operations in
static expressions.

In Ada 9X, basic operations ARE allowed in static expressions.

The reasons for this change are:

    - It removes an unnecessary restriction.  Programmers do not learn
      restrictions such as this one.  Instead, they learn the underlying
      assumptions (static expressions must be calculable at compile
      time, static expressions are always scalar, no user-defined static
      expressions, etc).  Any rule that doesn't fit into the underlying
      assumptions is ignored, until the user happens to accidentally
      write a program that violates the restriction.  Then, the user
      gets an error message, has no idea why, and is frustrated.

    - The implementation is trivial.

    - Any user who doesn't keep up with ARG rulings might think
      that was the rule anyway, and would probably report a bug
      to the compiler vendor.

There has been some question about the exact rule for the short-circuit
control forms.  In particular, if the user writes:

    False and then (some-non-static-expression)

is that a static expression?  The answer isn't terribly important --
either answer is trivial to implement.  But it is obviously important
that there be a well-defined answer.  We have chosen the answer, "Yes."
The exact rule is that an 'and then' or 'or else' expression is static
if both operands are static, or if the left operand is static and
determines the value of the expression.

We believe this is what the user would expect (if the user ever happened
to think about this issue).  The main use of short-circuit control forms
is when the right operand doesn't make sense in certain situations --
e.g. "(X /= null) and then (X.all = ...)" and that sort of thing.

Some have objected that this is the first time a static expression
contains a non-static sub-expression.  But that is exactly what one
would expect.  These are the only expressions where a subexpression
does not get evaluated at run time.  Therefore, these should be the
only expressions where a subexpression does not get evaluated at
compile time.  If the right operand would raise an exception, but is
not evaluated according to the run-time rules, then it should not be
evaluated according to the compile-time rules, and should not affect
the staticness of the expression.