Re: In-Out Parameters for functions

[Dmitry A. Kazakov <mailbox@dmitry-kazakov.de>]

On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen <hyrosen@mail.com>
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.

Wrong. Here is ARM 4.5:

"...For a sequence of predefined operators of the same precedence
level (and in the absence of parentheses imposing a specific
association), an implementation may impose any association of the
operators with operands so long as the result produced is an allowed
result for the left-to-right association, but ignoring the potential
for failure of language-defined checks in either the left-to-right or
chosen order of association."

allowed result /= unspecified result

The results are specified, they are all possibile ones produced by all
possible combinations exectution sequences. There is nothing wrong
with that, after all some people are still writing multitasking
programs...

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

Writting programs depending on evaluation order in a way that the
"correct" order is not specified, that is not a language problem.
Programmers should know what they are doing. Do you really believe
that tests will detect an "incorrect" order when specified by RM more
probably than when selected by the compiler? In my experience errors
like this are extremely difficult to detect, no matter whether an
order is specified by RM or not. This is why, [and for numerous other
reasons] I would like to see pure functions in Ada + procedures with
return giving all sorts of warnings when order is not *explicitly*
specified.

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

True, this argument would be invalid. But the argument, derived from
Gries position, is that the order shall be specified explicitly if
relevant to the program semantics. In all cases where the program
semantics does not depend on the order, it shall never be specified.
Both under- and overspecification are wrong.

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

I presume here the order is also arbitrary.

>     Point p := (x => cx, y => cy, z=> cz);

Anyway there are many orders contradicting each other:

type Point is record
   Z : Coordinate;
   Y : Coordinate;
   X : Coordinate;
end record;
[ + optionally, a nasty represenation clause stating some other, third
order ]

Is this order[s] irrelevant? Provided that programs are written by
idiots, I assure you that 50% of them would believe that keyed
associations will not override the native order of record fields. Or
do you think that the guessing the results of:

   Point P1 := (X => ReadCoord, Y => ReadCoord, Z => ReadCoord);
   Point P1 := (ReadCoord, ReadCoord, ReadCoord);
   Point P1 := (Y => ReadCoord, others => ReadCoord);

should be blessed as a symphony of safety and maintainability?

--
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de