Re: In-Out Parameters for functions

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

Hyman Rosen wrote:

> David Starner wrote:
> 
>> Why should buggy code work? 
> 
> I don't think you understand. As Ada stands now, it is perfectly
> legal to write code which has unspecified results due to order of
> execution. In general, the compiler cannot know whether particular
> code has such order dependencies or not, and so cannot reliably
> warn of such uses. Therefore, it's possible for such code to slip
> undetected into production, and to survive testing because the
> order chosen by the compiler is the "correct" one. Then some change
> occurs in the environment, such as changing optimization level,
> or changing platform, and now the compiler makes a different choice
> and the code stops working.
> 
> You cannot make the argument that raesonable care would prevent this.
> That is the same argument that C programmers make for the compiler not
> checking array bounds or pointer access, and Ada proponents roundly
> reject such arguments.
> 
> Therefore, the best thing to do is to eliminate the lack of specificity,
> so that a line of code will be executed in the same order always. Once
> this is in place, then depending on the order of evaluation within an
> expression will be no more problematic than depending on the order of
> execution of a pair of statements, and will not be "buggy". As for its
> utility, I submit that code like this:
>     Point p := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is perfectly sensible once you forget that order of evaluation was ever
> an issue and accept left-to-right as the natural way of things. Why is
> this statement any worse than
>     cx, cy, cz : Coord := ReadCoord;
>     Point p := (x => cx, y => cy, z=> cz);

What determines whether something is a bug?  On many projects it is in 
the mind of the programmer, and nowhere else.  I prefer to work on 
projects with defined and written testable requirements, and to allow 
these to define what is a bug.  If the SDP says to use SPARK, then any 
dependence on evaluation order is a bug, and it will be caught by the 
SPARK toolset.  If the SDP says something else, that will either 
establish guidelines that define functions with side-effects to be bugs, 
or which make calling two functions with mutual side-effects a bug.

Any of the the later approaches are fine with me, and are consistent 
with programming in Ada.  But you have to expect that I will regard any 
language revisions which attempt to change those bug definitions as a 
non-starter.  Notice that you are welcome to use SPARK if you want, and 
in fact I have worked with it on occasion.  But on other projects I have 
worked on, other definitions of bugs have been used.  To change the 
rules now would make lots of code obsolete.

Going through and reevaluating the programs according to the new rules 
is possible.  But without an automated toolset it is very expensive.  If 
there are significant upward incompatibilities in Ada 0Y, expect most 
compiler vendors to plan to provide such migration tools.  Now think 
about the effort required to develop the tools for your proposed change, 
and go away.  Note that SPARK is a subset of Ada, and such a toolset 
does exist for SPARK, so I am not saying it is impossible.  Just that 
you are in effect defining a new language, and the market for that 
language is currently served by SPARK and the SPARK toolset.

-- 
                                           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