Re: Right of Optimize Eager Evaluation Away

[Niklas Holsti <nholsti@icon.fi>]

Laurent Guerby wrote:
  [ snip ]
> 
> Is the potential raising of an exception the only language barrier
> to allow lazy evaluation for an optimizing compiler?
> 
> It looks like to me that the Ada language more or less intend that
> functions shouldn't have side effects, since by example it allows the
> compiler to evaluate arguments and thus potentially calling functions
> in any order, or allows only "in" parameters for the programmer.
> 
> The question is then, why stop at allowing any evaluation order and
> not just allow lazy evaluation as well?

I think you could define a language like that. The question is
how it would be related to the (current) Ada language. It seems
sure to be incompatible with side-effecting functions, even if
differences in exception-raising are allowed.

RM 1.1.3(8) lists the external effects that should be preserved by
optimisation. There seem to be some that can be sensibly used by
programmers without knowing the evaluation order, but yet cannot
be omitted totally without harming the program's result:

   - setting the value of imported or exported objects (independent
     of order if the functions used in the parameter expressions set
     different objects)

   - reading or updating atomic or volatile objects (may be independent
     of order if the functions read/update different objects).

In other words, some programs could use side-effects of this type,
and still work whatever evaluation order is chosen. So to apply lazy
evaluation, the compiler should ensure that no such effects can
occur as side-effects of the lazily evaluated functions.

In practice, I would add any task interactions to this list. Given a
function that interacts with tasks, it seems quite unlikely that the
compiler could prove that omitting the task interactions would not
make any significant difference to the external effects, yet there
must be many cases in which the evaluation order of such functions
is not in fact significant for the correctness of the program.

> pragma You_Can_Omit_Calls_To_This_If_The_Value_Is_Not_Needed (F);
> 
> (obviously a better name is needed ;-). If an expression involves only
> calls to pragma'ed functions (the Standard and String stuff could be
> in this category for example), then if the compiler finds out the
> result isn't needed in some run-time paths, it can omit the evaluation
> of the expression in those paths.

Isn't pragma Pure (10.2.1(18)) something like this? Is it too
restrictive for you?

Regards,
Niklas

Working at but not speaking for Space Systems Finland Ltd.