Re: In-Out Parameters for functions

["Robert I. Eachus" <rieachus@comcast.net>]

Hyman Rosen wrote:

> Think about it - if you write
>     s := Sin(x) + Cos(y)
> Ada requires that both arguments are evaluated, but doesn't specify the
> order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
> each time in a loop, but can hoist the calculations out, as you say. Why
> would specifying the order change this?

That may be why you keep butting your head against a brick wall.  If Ada 
said that in an equation like: s := Sin(1-x) + Cos(y); that the terms 
had to be evaluated left to right, that would say you couldn't evaluate 
Cos(y) before Sin(1-x) whether or not they were declared Pure.

Ada does allow compilers to combine calls to Pure functions, and if that 
is not okay, don't declare them Pure.  But that doesn't say that Pure 
functions can't have side effects.  It just changes what a compiler is 
allowed to do with Pure functions.  In fact, right now on the ARG list 
we are discussing a fix to 10.2.1 Elaboration Control which defines 
pragma Pure and pragma Preelaborate.  There are some new features in Ada 
0Y that require some wording changes, and we want them to be as 
restrictive as necessary, but no stricter.  In that discussion we have 
discussed exactly this issue.  (A Pure subprogram call can be 
eliminated, and if the subprogam has side-effects, well the programmer 
was warned.  No different from some other effects of optimizing compilers.

But note that what users have been warned about is that marking a unit 
as Pure may allow the optimizer to eliminate some calls.  The compilers 
are not allowed to call the function somewhere that it wouldn't be 
called otherwise.  The compiler must insure that a Pure function that 
would never be called in the canonical order is never called in the 
order the compiler selects.  And if two Pure functions have side 
effects, and both are called, the side effects must happen in the right 
order.

So the new rule that you are proposing would severly limit some very 
useful optimizations, unless you had exceptions for Pure functions, and 
predefined operators, and static expressions, and... Well you get the 
picture.  Soon you have more exceptions than case that are constrained 
by the rule, and all to insure that functions with side-effects are 
called in a single canonical order.

We prefer to have one easily understood set of rules.  Unfortunately in 
some useful cases these rules work out to "if you really want to be 
sure, install a block with an exception handler."  But this is based on 
twenty years of experience.  Users at all levels don't want strict 
execution orders in most cases, but they all seem to want very good 
optimization.

Also note incidently that what some users really do care about, and 
which has raised entirely too much discussion for something that will 
never be changed, is short-circut expression evaluation.  I don't know 
how many requests I have seen in various forms for redefining 'or' to 
mean 'or else' and 'and' to mean 'and then'.  (The proposals for the 
current meanings of 'and' and 'or' have lots of different syntax 
suggestions associated with them.)  But the real unalterable answer is 
NO! (Or maybe something more forceful.)  There is too much existing code 
that depends on the current rules and the cost of revising that code is 
totally out of proportion to the potential savings--which I don't even 
think exist.  The compiler can use short circut forms if the expression 
after 'and' or 'if' is marked Pure or a static expression, or only 
involves predefined expressions, etc.  (See the similar list above, 
which is what brought it to mind. ;-)

So the only cases where the proposed rule change would make a difference 
are exactly those cases that would have to be revised in existing code. 
And when you check on why the request was made, it often resulted from 
an error message at compile time.  The message can always be eliminated 
by changing the 'and' to 'and then' or the 'or' to 'or else'.  But in 
practice the programmer really has to think to be sure that is the right 
change.

It is the required thinking that seems to generate the revision 
requests. If 'and then' and 'or else' were the defaults then they 
wouldn't need to think during compilation, and they could wait for an 
exception at run-time. ;-)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush