why this construct causes aliasing problem in 2012 with functions allowing In Out?

why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Nasser M. Abbasi]

looking at http://www.slideshare.net/AdaCore/ada-2012

(typing it myself looking at the screen)

--------------------------
function change(x,y : in out integer) return integer is
  begin
   x := x*2;
   y := y*4;
   return x+y;
  end

  one , two : integer :=1;
  begin
    two := change(one,two)+ change(one,two);  -->
end
-----------------------------

They say it will generate

warning: result may differ if evaluated after actual in expression.

I understand that the order of calls in the A()+B() is not defined.
i.e. A() can be called first, then B(), or B() first then A().

But the result should still be the same either way. So what
is the problem?

Assume the first change(one,two) is called. Then after that
call, we will have
-------------------------
    two := 6 + change(2,4);   (1)

then the next change() is called using the updated actual
(the two on the LHS can't be updated yet)

    two := 6 + 20;   (2)
   
hence now two becomes 26.
------------------------
Same result will happen if we do it the other way

    two := change(2,4) + 6;   (1)

then the next change is called

    two := 20 + 6;   (2)
   
hence two is 26.

Is there another combination of mixing things up that I am
missing?

thanks,
--Nasser

Re: why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Nasser M. Abbasi]

On 6/20/2012 3:24 AM, Nasser M. Abbasi wrote:
> looking at http://www.slideshare.net/AdaCore/ada-2012

this was on slide 37 out of 46, in case someone wants to see it.

Re: why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Adam Beneschan]

On Wednesday, June 20, 2012 1:24:11 AM UTC-7, Nasser M. Abbasi wrote:
> looking at http://www.slideshare.net/AdaCore/ada-2012
> 
> (typing it myself looking at the screen)
> 
> --------------------------
> function change(x,y : in out integer) return integer is
>   begin
>    x := x*2;
>    y := y*4;
>    return x+y;
>   end
> 
>   one , two : integer :=1;
>   begin
>     two := change(one,two)+ change(one,two);  -->
> end
> -----------------------------
> 
> They say it will generate
> 
> warning: result may differ if evaluated after actual in expression.
> 
> I understand that the order of calls in the A()+B() is not defined.
> i.e. A() can be called first, then B(), or B() first then A().
> 
> But the result should still be the same either way. So what
> is the problem?

Obviously, it *would* be a problem if you said

    two := change(one,two) - change(one,two);

The language is designed to try to minimize order dependencies that could produce different results.  Asking it to make special cases for commutative operators when both operands are identical expressions, is asking too much.

It looks to me like whoever wrote that slide should have used "-" (or some other function) instead of "+", to avoid any possible confusion in people who realize that the order doesn't matter in this case.

                            -- Adam

Re: why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Dmitry A. Kazakov]

On Wed, 20 Jun 2012 07:56:12 -0700 (PDT), Adam Beneschan wrote:

> On Wednesday, June 20, 2012 1:24:11 AM UTC-7, Nasser M. Abbasi wrote:
>> looking at http://www.slideshare.net/AdaCore/ada-2012
>> 
>> (typing it myself looking at the screen)
>> 
>> --------------------------
>> function change(x,y : in out integer) return integer is
>>   begin
>>    x := x*2;
>>    y := y*4;
>>    return x+y;
>>   end
>> 
>>   one , two : integer :=1;
>>   begin
>>     two := change(one,two)+ change(one,two);  -->
>> end
>> -----------------------------
>> 
>> They say it will generate
>> 
>> warning: result may differ if evaluated after actual in expression.
>> 
>> I understand that the order of calls in the A()+B() is not defined.
>> i.e. A() can be called first, then B(), or B() first then A().
>> 
>> But the result should still be the same either way. So what
>> is the problem?
> 
> Obviously, it *would* be a problem if you said
> 
>     two := change(one,two) - change(one,two);
> 
> The language is designed to try to minimize order dependencies that could
> produce different results.  Asking it to make special cases for
> commutative operators when both operands are identical expressions, is
> asking too much.

Well, there exist possibilities to address the issue.

Let the language provided means to contract the evaluation order of some
operations.

Arguments having contracted side effects (like change(...) with its in out
parameters) would be illegal for any operation having no contracted
evaluation order, e.g. "-". This would make 
 
   two := change(one,two) + change(one,two)

illegal. But when the order is specified, e.g. left to right for string
"&", then side effects in arguments would be permitted:

   Name : String := Read (Socket) & Read (Socket);

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Randy Brukardt]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:2adb0da6-9b6e-4514-b703-f0a6261ecc5b@googlegroups.com...
> On Wednesday, June 20, 2012 1:24:11 AM UTC-7, Nasser M. Abbasi wrote:
>> looking at http://www.slideshare.net/AdaCore/ada-2012
>>
>> (typing it myself looking at the screen)
>>
>> --------------------------
>> function change(x,y : in out integer) return integer is
>>   begin
>>    x := x*2;
>>    y := y*4;
>>    return x+y;
>>   end
>>
>>   one , two : integer :=1;
>>   begin
>>     two := change(one,two)+ change(one,two);  -->
>> end
>> -----------------------------
>>
>> They say it will generate
>>
>> warning: result may differ if evaluated after actual in expression.

Apparently, they haven't implemented the aliasing checks completely yet, 
because this program is clearly illegal in Ada 2012. It violates 
6.4.1(6.17-18/3):

If a construct C has two or more direct constituents that are names or 
expressions whose evaluation may occur in an arbitrary order, at least one 
of which contains a function call with an in out or out parameter, then the 
construct is legal only if:

For each name N that is passed as a parameter of mode in out or out to some 
inner function call C2 (not including the construct C itself), there is no 
other name anywhere within a direct constituent of the construct C other 
than the one containing C2, that is known to refer to the same object.

If you consider the call to "+" to be C, then the uses of "One" and "Two" in 
one of the calls to Change are "known to refer to the same object" as the 
uses of "One" and "Two" in the other call to Change. Thus the call to "+" is 
illegal (not just a warning).

(I'm not sure if the response is accurately portrayed, so I'm not quite 
willing to call this a bug.)

                                           Randy.

Re: why this construct causes aliasing problem in 2012 with functions allowing In Out?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:ikgnsser1io8$.1ofpbj9hcpcio.dlg@40tude.net...
...
> Well, there exist possibilities to address the issue.

The issue *is* addressed. Either the slide or the summary of it is wrong.

> Let the language provided means to contract the evaluation order of some
> operations.
>
> Arguments having contracted side effects (like change(...) with its in out
> parameters) would be illegal for any operation having no contracted
> evaluation order, e.g. "-". This would make
>
>   two := change(one,two) + change(one,two)
>
> illegal.

No need to "make it" illegal; it IS illegal.

 But when the order is specified, e.g. left to right for string
> "&", then side effects in arguments would be permitted:
>
>   Name : String := Read (Socket) & Read (Socket);

I don't think the order is specified for "&"; that's the first I've heard of 
it. In any case, this is the actual rule used in Ada 2012 (it only applies 
when the order is unspecified, see the quote I previously posted).

The result is pretty complex, but normally, the compiler will tell you when 
you did something bad; otherwise, it isn't worth much energy to understand.

But this comes back to Adam's point: it wasn't worth trying to make a 
special case for operators that are communative when used alone, so there is 
no exception for "+" or any other case when the result does not actually 
depend on the order (but could have with a different body).

                                    Randy.