Re: Ada Core Technologies and Ada95 Standards

[eachus@spectre.mitre.org (Robert I. Eachus)]

In article <3162B080.490F@lfwc.lockheed.com> Ken Garlington <garlingtonke@lfwc.lockheed.com> writes:

   (Robert Dewar did a very good job of responding to this, I just
want to emphasize one point.)

  > How many attempts were made in the last three years to add a regression
  > test to the ACVC? How does that compare to the list of known bugs in Ada
  > compilers? I guess I'm still operating from ignorance: Dr. Dewar seemed
  > to think that it wasn't possible to try to put in regression tests for
  > every bug, but you're saying this is what is attempted? Perhaps we're
  > talking about different types of bugs?

    Exactly, a compiler bug as such is no reason for adding a test to
the ACVC suite.  A compiler bug that occurs because of a difficult or
unclear part of the reference manual, however, is a very good reason
to add an ACVC test.  My parenthetical remark was to point out that
not everything that is unclear in the reference manual should result
in an ACVC test.  There are, in fact, cases where the ambiguity of the
wording is intended to reflect an intent to leave that feature
undefined.  In some cases that is clearly expressed in the manual, in
other cases it is only stated by omission.

    This is probably best illustrated by example.  There are features
of the Ada language which occasionally make it difficult or impossible
for a compiler to enforce a strict order of evaluation for subprogram
parameters.  For example:

    function "+"(A: Apple; O: Orange) return Fruit_Collection is...

    function "+"(O: Orange; A: Apple) return Fruit_Collection is 
    begin return A+O; end "+";

    pragma INLINE("+");

    Is a construct that happens all over the place in abstract data
type definitions.  What would a requirement that parameters be
evaluated left to right mean in this case?  (Remember both calls get
in-lined.)  As a result, and also for efficiency reasons, Ada programs
are allowed to evaluate parameters in any order.

    Now to very gory detail.  In Ada 83, that order was defined to be
"evaluated in some order that is not defined by the language."  This
"accidently" outlawed evaluting parameters simultaneously.  Using
parameter expressions with side effects, especially the raising of
exceptions, allowed this to be tested, but the opinion of the ARG and
most of the Ada community was that such tests were pathological
programs and should not be incorporated into the test suite.  The very
valid fear was that such tests would result in some very useful
optimizations being removed from compilers.

    In Ada 95, the rule is stated as "These evaluations are done in
arbitrary order," and that phrase is defined in 1.1.4(18) to allow
compilers to ignore side effects.  (But not real dependencies between
operations, just side effects.)  This incidently results in a rule
that can be checked only with debuggers in many cases.  The practical
effect on users is nil.  If you have parameters with side effects, and
the order of evaluation is important to you, you need to pull those
expressions out of line in any case.
    
    One last try to aviod MEGO:

    So if a program had a procedure call with two parameters:

        B: Integer := 5;
        ...
        Foo(A,B);

    ...and evaluation of A changed the value of B:

      function A return Integer is begin B := -3; return 6; end A;

    ...and the second parameter is declared to be of subtype Positive.
Then in Ada 83 an ACVC test program could check that either the call
did not raise Constraint_Error, or that B had the value 5 in the
exception handler.  That sort of test was considered to be not very
helpful, in fact downright harmful, since if B was in a temporary
register it had to be stored before the constraint check.  Ouch!

    Such tests were considered to be counterproductive, and Ada 95
such tests are defined not to work.  (See 11.6(6), and read the
note--the reordering permissions only cut in if an exception is raised
in (a) canonical order of execution.)  The value of B is allowed to be
5 in the execption handler, even if it was the check on B that put the
program in the handler.  (If you do care, you just have to make sure
that the value of B is set outside the scope of the handler.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...