Re: In-Out Parameters for functions

[Stephen Leake <stephen_leake@acm.org>]

"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:

> Look at this formulae:
> 
>   F(A) + G(A);
> 
> If F is permitted to change value of A then the result of the formulae may
> depend on order of computation. And this is obviously dangerous, because the
> formulae looks as typical mathematical expression, where this effect usually
> is not anticipated. 

Hmm. Let F be Sqrt (Ada.Numerics.Float_Random.Random), and G be
Ada.Numerics.Float_Random.Random. Then we see that Ada _requires_ the
behavior you are describing. So it's clearly a Good Thing :).

Which is pretty ironic, since one reason
Ada.Numerics.Float_Random.Random is defined as a function is to
satisfy some notion of "mathematical purity". The closest the AARM
comes to saying that is in AARM A.5.2:

32.b
          Reason: The requirement for a level of indirection in
          accessing the internal state of a generator arises from the
          desire to make Random a function, rather than a procedure.

Given that Ada _requires_ that users be allowed to write expressions
with the order dependency you describe, what would be wrong with defining
Ada.Numerics.Float_Random.Random with parameter mode "in out"? 

Or, to be fully consistent, Ada.Numerics.Float_Random.Random should be
a procedure.

I'll have to remember to never add two functions of a random number
together in one expression, if I want truly portable results. I don't
think I actually do that, anyway; there are usually intermediate
values when a final result depends on more than one random number. 

But I suspect casual users of random numbers will not be worried about
precisely repeatable results from different compilers for this kind of
expression.

Users will always be able to shoot themselves in the foot. The
language should help them avoid that, but it cannot prevent it. The
language needs to find a reasonable balance between prevention of bad
effects and expressive power. In this particular case I think Ada
strayed too far to the "prevention" side. 

C++, on the other hand, is too far on the "expressive" side in
general.

-- 
-- Stephe