Re: In-Out Parameters for functions

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

I said:
>>If a user wants to, he can use other language rules (and code that
>>makes it obvious that it is intentional) to force a particular
>>evaluation order. But it is much harder to do that than to make the
>>code agnostic about evaluation order, and that is intentional.

Stephen Leake wrote:

> Ok. Some of us don't understand why it is harder; that would be a
> useful thing to talk about.

I am probably not the best one to ask about it, since believe it or not, 
  one of my personal fights during the Ada 9X development process was 
that it should be POSSIBLE to force an evaluation order.

But I'll give it a try.  In modern CPUs synchronization calls that allow 
"precise" interrupts are very expensive, in an execution time sense of 
course. In Ada, this means that requiring variables to have specific 
values when Constraint_Error is raised.  Or for that matter when any 
predefined exception is raised.  But in practice the interesting cases 
are for Constraint_Error.

If there is a specified order, then someone can write a test that raises 
  Constraint_Error in "interesting" places, and looks at the values of 
variables in the handler.  In Ada 83, there was a huge, nasty AI, 
AI-315, that looked at this issue and RM 11.6 in general.  (Notice that 
section 11.6 Exceptions and Optimization in the Ada 83 manual 
corresponds to 11.6 in Ada 95. This was very intentional.)

The debate over what to do about this "problem" in Ada 83 was never 
resolved.  In theory, the freedoms granted in (Ada 83) 11.6 could be 
used to make  almost any program do anything.  But in practice there 
were some very strict rules that made it almost impossible for compilers 
to "take advantage" of these freedoms.

The tension was that the compiler vendors wanted to get rid of some of 
the more onerous requirements.  But those who wrote programs which 
needed to raise (and handle) Constraint_Error were of course concerned 
that Constraint_Error not turn into something where any attempt to 
handle Constraint_Error could cause the hard drive to be overwritten.

The current solution as far as I am concerned goes a little too far in 
the direction of allowing optimizations at the expense of making 
exception handlers more difficult to write.  In fact, you sometimes have 
to insert a call to an independent subprogram just to guarantee the 
necessary semantics. "An independent subprogram is one that is defined 
outside the library unit containing the construct whose check failed, 
and has no Inline pragma applied to it. Any assignment that occurred 
outside of such abort-deferred operations or independent subprograms can 
be disrupted by the raising of the exception, causing the object or its 
parts to become abnormal, and certain subsequent uses of the object to 
be erroneous, as explained in 13.9.1." (RM 11.6(6) where else?)

As far as programs that don't have to deal with Constraint_Error 
handlers are concerned though, the situation is much better.  If you 
split a complex expression into a series of assignment statements, the 
order of evaluation is not guaranteed, but you do get "as if" semantics. 
  (Again, absent Constraint_Error being raised.)

-- 
                                           Robert I. Eachus

"The only thing necessary for the triumph of evil is for good men to do 
nothing." --Edmund Burke