Re: In-Out Parameters for functions

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

I don't follow, and I would like to, because I find [IN] OUT params
for functions very useful. Could you please elaborate on that a bit
more?

> And only one seems still valid: it is about
> complex expressions where a function call may be used as an actual argument
> for another function. I believe that that objection will be covered by the
> following 3rd rule for IN OUT parameters for functions:
> 
> 3) in a function call, an actual argument that corresponds to IN OUT formal
>    parameter must be a variable, and must be preceeded by the keyword VAR.
> 
> For example:
> 
>   X := Random(var Y);
> 
> With this rule any confusion becomes improbable, and readability flourishes.
> 

Looks like you are proposing a new keyword, which is likely to have
been used as variable name. This rarely goes in.

Regards,
Wojtek


PS. When I last raised this issue, Randy Buckhard was kind enough to
explain it to me in this post:

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&frame=right&rnum=31&thl=1052791649,1052608147,1051351022,1051243512,1051879196,1051837965,1051735064,1051655015,1051488994,1051348161,1051239613,1051695835&seekm=5ad0dd8a.0307120438.6aac89b5%40posting.google.com#link34

And asked wether we "havd to discuss this AGAIN?" 

:-)

RE: In-Out Parameters for functions

[amado.alves]

"I don't follow, and I would like to, because I find [IN] OUT params
for functions very useful. Could you please elaborate on that a bit
more?"
Maybe the most common example is the idiom (illegal in Ada):
  while Next (Item) loop
    Do_Something (Item);
  end loop;
where the Next function returns false in no more items are available,
and Item is an (illegal) in out parameter which holds the result of
a 'successful' call (and holds garbage on unsuccessful calls--this is 
the ugly bit). The above idiom is perhaps the most clean solution for
the associated problem. I know I invariably use it when I write in C.
(Sorry for the possibly illformatted text. 
I'm stuck with a crapy webmail system.)

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]


"amado.alves" <amado.alves@netcabo.pt> a �crit dans le message de news:mailman.7.1074873660.2270.comp.lang.ada@ada-france.org...
>"I don't follow, and I would like to, because I find [IN] OUT params
>for functions very useful. Could you please elaborate on that a bit
>more?"
>Maybe the most common example is the idiom (illegal in Ada):
>  while Next (Item) loop
>    Do_Something (Item);
>  end loop;

I understand pros and cons of  in out for functions, but this one is really not convincing.
I always write:

while More_To_Come loop
   Get (Item);
   Do_Something (Item);
end loop;

Of course, Get raises an exception if there are no more items available, so it is a lot more secure.
Well, of course, security and exceptions are not an issue when you program in C...

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> I don't follow, and I would like to, because I find [IN] OUT params
> for functions very useful. Could you please elaborate on that a bit
> more?
>
> > And only one seems still valid: it is about
> > complex expressions where a function call may be used as an actual argument
> > for another function. I believe that that objection will be covered by the
> > following 3rd rule for IN OUT parameters for functions:
> > 
> > 3) in a function call, an actual argument that corresponds to IN OUT formal
> >    parameter must be a variable, and must be preceeded by the keyword VAR.
> > 
> > For example:
> > 
> >   X := Random(var Y);
> > 
> > With this rule any confusion becomes improbable, and readability flourishes.
> > 

I don't get clear - which point should be elaborated? (for me all that looks
pretty straightforward, complete and unambiguous -:)

> Looks like you are proposing a new keyword,

Actually no - it was more a part of live discussion, then a polished proposal,
so "var" there was just an example of what may be used there. Although I am
not so frightened by new keywords, in this particular case there is no strong
need of one: for example, ACCEPT reserved word may be used here:

   X := Random(accept Y);

or simply IN OUT:

   X := Random(in out Y);

so just choose what you like better -:)

> PS. When I last raised this issue, Randy Buckhard was kind enough to
> explain it to me in this post:
> ...
> And asked wether we "havd to discuss this AGAIN?" 

I don't think that here is any problem. Certainly, Ada language designers
have a good reason to sigh when this issue pops up again. But nevertheless,
we programmers not only have a right to discuss the language issues that
disturb us, but even must do that.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> I don't get clear - which point should be elaborated? 
> (for me all that looks pretty straightforward, 
> complete and unambiguous -:)

This worry is unclear to me:

>> And only one seems still valid: it is about complex 
>> expressions where a function call may be used as 
>> an actual argument for another function. 

I don't see how adding IN OUT arguments could make things worse in
this matter. A function can have side effects on global state, it can
have side effects on its IN paramerters (by using the Rosen trick). I
just don't see how documenting those side effects in the function
specification could make things worse.


> (...) But nevertheless, we programmers not only have 
> a right to discuss the language issues that disturb us,
> but even must do that.

I guess :-)


Regards,
Wojtek

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> This worry is unclear to me:
>
> >> And only one seems still valid: it is about complex 
> >> expressions where a function call may be used as 
> >> an actual argument for another function. 
>
> I don't see how adding IN OUT arguments could make things worse in
> this matter.

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. Then notice that the expressions often may be more 
complicated... something like this:

  F(A, B) * G(C, F(A, D)) + G(A, B) * F(C, G(A, D))

Add to that possible optimization issues, and probably you will see some
reason to worry.

Expressions with functions are too important part of a language like Ada,
where various scientific formulas are used very often in typical applications.
Therefore this part must be made safe enough and must respect mathematical
viewpoint, which is naturally and commonly associated with formulas.

> A function can have side effects on global state, it can
> have side effects on its IN paramerters (by using the Rosen trick).

Yes, but if a programmer produces/uses side effects on global state in a
function and especially if he changes IN parameters by any trick, he at least
knows that he is doing irregular things - and takes responsibilty for that.
Providing IN OUT parameters for functions we remove this mental warning/deterrent.

> I just don't see how documenting those side effects in the function
> specification could make things worse.

The problem is that it may be not enough to document those possible side
effects in the function's specification - and the above point is exactly
about that. By requiring it to be documented in call site also, we ensure
that the caller is aware of possible side effect there and agreed with it.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert A Duff]

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

> Wojtek Narczynski wrote:
> 
> > This worry is unclear to me:
> >
> > >> And only one seems still valid: it is about complex 
> > >> expressions where a function call may be used as 
> > >> an actual argument for another function. 
> >
> > I don't see how adding IN OUT arguments could make things worse in
> > this matter.
> 
> 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.

That might be a good argument against side effects in functions, but
Wojtek Narczynski is asking why, given that side effects in functions
are allowed in Ada, is it damaging to allow side effects on 'in out'
parameters.  The F and G functions above might both write upon global
variable X.  How could writing upon parameter A be any worse?

> > A function can have side effects on global state, it can
> > have side effects on its IN paramerters (by using the Rosen trick).
> 
> Yes, but if a programmer produces/uses side effects on global state in a
> function and especially if he changes IN parameters by any trick, he at least
> knows that he is doing irregular things - and takes responsibilty for that.
> Providing IN OUT parameters for functions we remove this mental
> warning/deterrent.

The person reading the body of F or G can of course know what's going
on.  But the person reading the expression "F(A) + G(A)" has no idea.
Allowing 'in out' parameters would not change that fact.

> > I just don't see how documenting those side effects in the function
> > specification could make things worse.
> 
> The problem is that it may be not enough to document those possible side
> effects in the function's specification - and the above point is exactly
> about that. By requiring it to be documented in call site also, we ensure
> that the caller is aware of possible side effect there and agreed with it.

I agree that requiring syntax at the call site to indicate side effects
would be a good idea.  But that's not an argument against 'in out'
parameters of functions.

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

> > 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.
>
> That might be a good argument against side effects in functions, but
> Wojtek Narczynski is asking why, given that side effects in functions
> are allowed in Ada, is it damaging to allow side effects on 'in out'
> parameters.  The F and G functions above might both write upon global
> variable X.  How could writing upon parameter A be any worse?

The F and G functions may both update global variable X, but neither of them
uses that X for computing the result, and this is what makes difference.

Commonly, if several functions may be used in the same expression then they
either update some global variable or use it for computing result, but not both.
That is, if one of them updates a global variable then others should not use
this variable for computation of their results.

So, writing upon global variables in functions may be safe enough - while we
honor the above rule.

But parameters of a function are expected to participate in the computation
of the result, and this is common case. So, even a particular parameter in
a function is not used for computation of the result of *this* function, it
easily may be passed to another function within the same expression and
influence its result.

Therefore, IN OUT parameters in functions will not be worse than the ability
of functions to change global variables if we forbid use of such functions in
expressions, that is:

  If at least one parameter of a function is in IN OUT mode then the function
  cannot be used in a compound expression. This function's call must always
  constitute the whole RHS of an assignment.

or less restrictive rule:

  If at least one parameter of a function is in IN OUT mode then in any
  expression in which this function is called all other calls may be for
  parameterless functions only.





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 26 Jan 2004 00:02:45 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Therefore, IN OUT parameters in functions will not be worse than the ability
>of functions to change global variables if we forbid use of such functions in
>expressions, that is:
>
>  If at least one parameter of a function is in IN OUT mode then the function
>  cannot be used in a compound expression. This function's call must always
>  constitute the whole RHS of an assignment.
>
>or less restrictive rule:
>
>  If at least one parameter of a function is in IN OUT mode then in any
>  expression in which this function is called all other calls may be for
>  parameterless functions only.

What about:

F(X) and then F(X)

The rule, if any, should prevent using an object in IN OUT mode in an
expression where the evaluation order is not specfied by the language.

Looks much like the aliasing problem:

procedure Foo (X, Y : in out Object) is
begin
   X := F(X) + F(Y); -- Is this legal?
   Foo (X, X); -- And this?
end Foo;

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

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> The F and G functions may both update global variable X, but neither of them
> uses that X for computing the result, and this is what makes difference.

Oh, I can easily imagine functions H and J that both do read
_and_write_ a global variable Y.

Perhaps just expressions with value (and side effect) dependent on the
order of computation, should not be allowed. It would be a good rule,
but it is too late for it, I guess.

Or the order of computation should be explicitly defined as left to
right. Or maybe it already is, and I don't know about it :-)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

> > The F and G functions may both update global variable X, but neither of them
> > uses that X for computing the result, and this is what makes difference.
>
> Oh, I can easily imagine functions H and J that both do read
> _and_write_ a global variable Y.

And use this global variable Y for computing their results? If you really can
easily imagine all that mess for professional Ada programmers then perhaps you
must be sent back to undergraduate courses -;) .

Note that there are fully legitimate and safe cases where functions actually
read and write global variables, but *not use those variables for computing
thier results*. (I think that in majority of reasonable cases where several
functions use the same global variable both for reading and writing, that
global variable is an array).

> Perhaps just expressions with value (and side effect) dependent on the
> order of computation, should not be allowed. It would be a good rule,
> but it is too late for it, I guess.

You are in hurry? You expect end of the world? -:)  Well, I think that you'll
be able to formulate some good *exact and complete* rule of this kind not
earlier than the ARG will call for proposals for Ada1Z -;) .




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> >Therefore, IN OUT parameters in functions will not be worse than the ability
> >of functions to change global variables if we forbid use of such functions in
> >expressions, that is:
> >
> >  If at least one parameter of a function is in IN OUT mode then the function
> >  cannot be used in a compound expression. This function's call must always
> >  constitute the whole RHS of an assignment.
> >
> >or less restrictive rule:
> >
> >  If at least one parameter of a function is in IN OUT mode then in any
> >  expression in which this function is called all other calls may be for
> >  parameterless functions only.
>
> What about:
>
> F(X) and then F(X)

Naturally, forbidden. Perhaps the wording of my (above) "less restrictive rule"
was not good enough, but I meant that "all other calls" includes other calls
of the mentioned function (which has an IN OUT parameter), and that the meaning
is entirely static, not dynamic. So, probably at least one correction should
be made in this rule - replacing "calls" by "references":

  If at least one parameter of a function is in IN OUT mode then in any
  expression in which this function is called all other references may be
  for parameterless functions only.

Well, I leave the exact wording of the rule to native English speakers -;) .

> The rule, if any, should prevent using an object in IN OUT mode in an
> expression where the evaluation order is not specfied by the language.

Yes, certainly. And I'd forbid that even if that order IS specified but may be
non-obvious... actually I'd forbid that in all cases where that order can
matter at all - for anything.

> Looks much like the aliasing problem:
>
> procedure Foo (X, Y : in out Object) is
> begin
>   X := F(X) + F(Y); -- Is this legal?
>   Foo (X, X); -- And this?
> end Foo;

Perhaps legal, but awfully wrong -;)




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> Hello,
> 
> > The F and G functions may both update global variable X, but neither of them
> > uses that X for computing the result, and this is what makes difference.
> 
> Oh, I can easily imagine functions H and J that both do read
> _and_write_ a global variable Y.
> 
> Perhaps just expressions with value (and side effect) dependent on the
> order of computation, should not be allowed. It would be a good rule,
> but it is too late for it, I guess.

The issue is not so simple.  Consider, for example:

    P(F(...), G(...));

and F does "new T", and G also does "new T".  Thus both F and G are both
reading and writing the same variable (namely, the Storage_Pool of T).
But this example is (probably) harmless, even though the 'Address of the
allocated objects will be different depending on the evaluation order.

The same would occur if you have a Unique_Id function that increments a
global integer, and returns a unique number (private type) -- clients
aren't supposed to care about the order of numbers -- just that they're
unique.  If F and G both call Unique_Id, there's no harm.

> Or the order of computation should be explicitly defined as left to
> right. Or maybe it already is, and I don't know about it :-)

No, order of parameter eval is not required to be left-to-right in Ada.

- Bob

Re: In-Out Parameters for functions

[Robert A Duff]

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

>   If at least one parameter of a function is in IN OUT mode then the function
>   cannot be used in a compound expression. This function's call must always
>   constitute the whole RHS of an assignment.

But this allows:

    A(I) := F(I);

where A is an array, and F modifies its parameter I.

- Bob

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert A Duff wrote:
> But this allows:
>     A(I) := F(I);
> where A is an array, and F modifies its parameter I.

You know, Java hasn't lost any business by specifying
order of evaluation. There's a lot to be said for strict
left-to-rightness, operands before operation. Under that
paradigm, the compiler would evaluate I and use it to fix
the identity of the object referred to by A(I). Then it
calls F with I as the parameter. If you said
     A(I) := F(I) + I
and F changed I, the sum would use the changed I. If you
said
     A(I) := I + F(I)
the sum would use the original I.

Of what use is lack of specificty? I think the days where
this could significant speed difference in the generated
code are long gone.

Re: In-Out Parameters for functions

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > But this allows:
> >     A(I) := F(I);
> > where A is an array, and F modifies its parameter I.
> 
> You know, Java hasn't lost any business by specifying
> order of evaluation. There's a lot to be said for strict
> left-to-rightness, operands before operation.

True.  At least that way, you don't get different answers on different
implementations.

But it's still hard to understand statements/expressions that have
mutually-depndent side-effecting operations in the middle.
It does seem of some value to attempt to make sure "order doesn't
matter".

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Robert A Duff wrote:

>   If at least one parameter of a function is in IN OUT mode then the function
>   cannot be used in a compound expression. This function's call must always
>   constitute the whole RHS of an assignment.
>
> But this allows:
>
>    A(I) := F(I);
>
> where A is an array, and F modifies its parameter I.

Yes, you are certainly right, and I overlooked this standard trap (well-known
from Algol-60 times). But nevertheless I think that in this particular context
- when we are talking about the difference between changing global variables
and IN OUT parameters, this counter-example is not valid - I think that there
is no significant difference between using global variable as index and that
in the example.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert A Duff wrote:
> It does seem of some value to attempt to make sure "order doesn't matter".

But since this will never be the case in Ada, the next best thing is to
define the order.

Re: In-Out Parameters for functions

[Stephen Leake]

"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

Re: In-Out Parameters for functions

[Stephen Leake]

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > It does seem of some value to attempt to make sure "order doesn't matter".
> 
> But since this will never be the case in Ada, the next best thing is to
> define the order.

Hmm. It's very unlikely that Ada will change to define the order of
execution in expressions. There are good reasons to leave it undefined
(different optimizations for different targets or speed/space goals,
for example), and changing it would be work for existing compilers.

On the other hand, I can enforce a style rule that says "don't write
expressions whose result depends on order of execution". I could even
write an ASIS tool to help enforce that.

I think this style rule is what Robert is suggesting here.

So I'm not clear what you are saying, Hymen.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 26 Jan 2004 23:19:49 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> >Therefore, IN OUT parameters in functions will not be worse than the ability
>> >of functions to change global variables if we forbid use of such functions in
>> >expressions, that is:
>> >
>> >  If at least one parameter of a function is in IN OUT mode then the function
>> >  cannot be used in a compound expression. This function's call must always
>> >  constitute the whole RHS of an assignment.
>> >
>> >or less restrictive rule:
>> >
>> >  If at least one parameter of a function is in IN OUT mode then in any
>> >  expression in which this function is called all other calls may be for
>> >  parameterless functions only.
>>
>> What about:
>>
>> F(X) and then F(X)
>
>Naturally, forbidden. Perhaps the wording of my (above) "less restrictive rule"
>was not good enough, but I meant that "all other calls" includes other calls
>of the mentioned function (which has an IN OUT parameter), and that the meaning
>is entirely static, not dynamic. So, probably at least one correction should
>be made in this rule - replacing "calls" by "references":
>
>  If at least one parameter of a function is in IN OUT mode then in any
>  expression in which this function is called all other references may be
>  for parameterless functions only.

This limitation has no sense for short-circuit operations.

>Well, I leave the exact wording of the rule to native English speakers -;) .
>
>> The rule, if any, should prevent using an object in IN OUT mode in an
>> expression where the evaluation order is not specfied by the language.
>
>Yes, certainly. And I'd forbid that even if that order IS specified but may be
>non-obvious... actually I'd forbid that in all cases where that order can
>matter at all - for anything.

The problem is that this cannot be checked in a reasonable way because
of aliasing. And I am afraid that for Ada newcomers the effect would
be even more frustrating than in the case accessibility checks. If we
had pure functions there could be a more attractive (?) aternative: to
fix the evaluation order if a non-pure function gets involved.

>> Looks much like the aliasing problem:
>>
>> procedure Foo (X, Y : in out Object) is
>> begin
>>   X := F(X) + F(Y); -- Is this legal?
>>   Foo (X, X); -- And this?
>> end Foo;
>
>Perhaps legal, but awfully wrong -;)

A bound error? (:-))

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

Re: In-Out Parameters for functions

[Peter Amey]

Interesting sub thread.  It has raised all the nastiness of function 
side effects, evaluation order dependency and aliasing.  FWIW, avoiding 
these kinds of issue were a major motivator in the design of SPARK. 
SPARK functions never have side effects, the language is free from 
evaluation order dependencies and aliasing is efficiently detected in 
all cases.  These steps, in our opinion, are a necessary precondition 
for rigorous static analysis.

regards

Peter

Alexandre E. Kopilovitch wrote:
> Wojtek Narczynski wrote:
> 
> 
>>This worry is unclear to me:
>>
>>
>>>>And only one seems still valid: it is about complex 
>>>>expressions where a function call may be used as 
>>>>an actual argument for another function. 
>>
>>I don't see how adding IN OUT arguments could make things worse in
>>this matter.
> 
> 
> Look at this formulae:
> 
>   F(A) + G(A);
> 
> [snip]

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 02:26:17 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

>Robert A Duff wrote:
>> It does seem of some value to attempt to make sure "order doesn't matter".
>
>But since this will never be the case in Ada, the next best thing is to
>define the order.

There could be also an opposite point of view. Fixing the evaluation
order you strengthen the "precondition" of the code. I believe that D.
Gries in his The Science of Programming argued to do exactly the
opposite. For example, that the case statement should run all
alternatives in parallel when more than one guard is open etc. His
point, if I correctly remember, was lesser precondition, more general
and better code. Actually this is the old "and" vs. "and then" debate.

Just as an independent observer. (:-))

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

Re: In-Out Parameters for functions

[Wojtek Narczynski]

> And use this global variable Y for computing their results? 
> If you really can easily imagine all that mess for professional Ada 
> programmers then perhaps you must be sent back to undergraduate courses -;) .

Yes, I can imagine that. If the professional programmer only looks at
the specification of those functions, he or she will not know. This is
why I think F + G is worse than F(Y) + G(Y), even if the result of
this expression depends on the order of evaluation of F and G.
 
> Note that there are fully legitimate and safe cases where functions actually
> read and write global variables, but *not use those variables for computing
> thier results*. (I think that in majority of reasonable cases where several
> functions use the same global variable both for reading and writing, that
> global variable is an array).

For function with side effects to remain a function, you need to
consider all its inputs and outputs. It doesn't matter wether you
'return' a result or store it in a global variable.

> You are in hurry? You expect end of the world? -:)  Well, I think that you'll
> be able to formulate some good *exact and complete* rule of this kind not
> earlier than the ARG will call for proposals for Ada1Z -;) .

No rule that would break a lot of code will ever go in.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> The issue is not so simple.  Consider, for example:
> 
>     P(F(...), G(...));
> 
> and F does "new T", and G also does "new T".  Thus both F and G are both
> reading and writing the same variable (namely, the Storage_Pool of T).

Point taken, not simple.

> No, order of parameter eval is not required to be left-to-right in Ada.

So it looks to me like there is indeed an issue with in out parameters
(and global state)  for functions that the same program can behave
differently compiled with different compilers.

But as you pointed out, vast majority of side effects are commutative
(allocation, counters).

I also suspect that in real implementations the order is left to
right. Unless some optimizations are in effect. And unless
you-know-who has hidden his secret compiler of mass compilation
you-know-where.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 27 Jan 2004 02:26:17 GMT, Hyman Rosen <hyrosen@mail.com>
: wrote:
: 
:>Robert A Duff wrote:
:>> It does seem of some value to attempt to make sure "order doesn't matter".
:>
:>But since this will never be the case in Ada, the next best thing is to
:>define the order.
: 
: There could be also an opposite point of view. Fixing the evaluation
: order you strengthen the "precondition" of the code.

And how does it help, anyway? If functions have side effects,
you have to consider all values affected and affecting the function,
recursively. Is that practial (or, the next best thing)? Example:

#include <iostream>

class Weird {
  int const modulus;
public:
  Weird(int step) : modulus(step) {}
  int state() const;
};

int Weird::state() const {
  extern int global_state;
  return ++global_state % modulus;
}

int global_state = 2;

bool operator==(const Weird& a, const Weird& b) {
  return a.state() == b.state();
}

int main(void)
{
  Weird x(3), y(4);

  const Weird& w1 = x, w2 = y;

  while (w1 == w2) {
    std::cout << "we have reached the predecessors of " << w1.state()
	      << " and " << w2.state() << std::endl;
  }
  return 0;
}

Re: In-Out Parameters for functions

[Robert A Duff]

Peter Amey <peter.amey@praxis-cs.co.uk> writes:

>... SPARK functions never have side effects, ...

SPARK is consistent.  No side effects involving globals, no side effects
involving parameters.  No side effects.  Simple.

Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
so long as you don't document them on the function spec.

- Bob

Re: In-Out Parameters for functions

[Hyman Rosen]

Stephen Leake wrote:
> Hmm. It's very unlikely that Ada will change to define the order of
> execution in expressions. There are good reasons to leave it undefined
> (different optimizations for different targets or speed/space goals,
> for example), and changing it would be work for existing compilers.

Those are not good reasons, those are "We've Always Done It This Way"
reasons. It would be some work for compiler vendors, but it would be
only a benefit for Ada programmers. For the typical case where order
doesn't matter, adopting the new rule doesn't hurt optimization since
the compiler is always free to use its as-if license to do things in
any order it wants to. And Ada compilers already know how to do things
in defined order since they must compile 'and-then' and 'or-else'.

You are arguing that for the convenience of compiler vendors, programmers
should be subjected to a gratuitous source of non-portability, which they
must avoid by being careful when they code, rather than having the language
protect them. Oddly enough, this is the attitude that Ada proponents are
always denigrating about C++.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 27 Jan 2004 12:37:21 -0500, Hyman Rosen wrote:
> For the typical case where order
> doesn't matter, adopting the new rule doesn't hurt optimization since
> the compiler is always free to use its as-if license to do things in any
> order it wants to.

It would quite a bit of work to prove that two functions don't have side
effects, especially in the face of exceptions. It could easily call for
intra-unit optimizations, and many cases just won't be possible.

> You are arguing that for the convenience of compiler vendors,
> programmers should be subjected to a gratuitous source of
> non-portability, which they must avoid by being careful when they code,
> rather than having the language protect them. Oddly enough, this is the
> attitude that Ada proponents are always denigrating about C++.

Ada usually protects programmers by making things illegal, in the sake of
clarity, rather then adding rigid rules. In a practical sense, the only
times when the order of execution of f(x) + g(x) matters is when there's
tight hidden coupling. Ada usually discourages tight hidden coupling; why
make a rule whose only goal is to make it easier to do? (Yes, I know about
the random case, but by definition, programmers can't depend on the
results of a random function, and I think that includes the same program
compiled with different optimization settings.)

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> It would quite a bit of work to prove that two functions don't have side
> effects, especially in the face of exceptions. It could easily call for
> intra-unit optimizations, and many cases just won't be possible.

That's fine. In those cases the compiler is obviously not going to
choose evaluation order based on efficiency, so specifying the order
will not pessimize the code.

> Ada usually discourages tight hidden coupling

How does it do that, aside from forbidding functions to have
*out parameters?

Re: In-Out Parameters for functions

[Robert A Duff]

Hyman Rosen <hyrosen@mail.com> writes:

> Stephen Leake wrote:
> > Hmm. It's very unlikely that Ada will change to define the order of
> > execution in expressions. There are good reasons to leave it undefined
> > (different optimizations for different targets or speed/space goals,
> > for example), and changing it would be work for existing compilers.
> 
> Those are not good reasons, those are "We've Always Done It This Way"
> reasons. It would be some work for compiler vendors, but it would be
> only a benefit for Ada programmers.

Probably true.

>...For the typical case where order
> doesn't matter, adopting the new rule doesn't hurt optimization since
> the compiler is always free to use its as-if license to do things in
> any order it wants to.

No, that is not correct.  Compilers cannot tell, at compile time,
whether the order matters (in many cases).  Therefore, they cannot
optimize many of the cases where order does not matter, if the rule were
changed to "left-to-right".

On the other hand, I suspect that order-changing optimizations are not
really all that important for speed.

>... And Ada compilers already know how to do things
> in defined order since they must compile 'and-then' and 'or-else'.

Yes, and they also know that statements in a sequence must be executed
in order.  But that certainly does *not* mean that it would be easy to
change existing compilers to obey left-to-right order for subprogram
parameters.

There is *no way* that Ada will change to require left-to-right.  It's
simply too hard for existing compilers, even if you can convince us
compiler writers that the potential optimizations don't matter much.
And there is *no way* the rules will change to require side effects to
be evident to the compiler (and user!) at the call site.  Too much
incompatibility.  So we're stuck, like C and C++, with an order that's
up to the whim of the compiler writer.

> You are arguing that for the convenience of compiler vendors, programmers
> should be subjected to a gratuitous source of non-portability, which they
> must avoid by being careful when they code, rather than having the language
> protect them. Oddly enough, this is the attitude that Ada proponents are
> always denigrating about C++.

Right.

- Bob

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

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

"Random" is very special case, in which an intention is quite opposite to what
is common in normal "regular" circumstances. In "regular" circumstances we want
the same result for the same input data and we are in trouble when this does
not happen for any reason (for example, after moving to another compiler). But
when we use Random we want and expect some diversity of the results (perhaps
intermediate results), and the changes produced by the effect mentioned above
not necessary will defeat our purpose. Anyway, if you use Random for some stable
results you should always be very careful with all computations as well as with
mathematical background for them; so in such a case this effect is just a minor
(and easy) detail among various issues.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> "Random" is very special case

So is any function which reads data from an external source,
so it's not quite as special as you would have us believe.

It would be nice to be able to say (in my pidgin Ada)
	Point p := (x => get(), y => get(), z => get());
and know that the members would be read in the order given,
not in some arbitray order.

Re: In-Out Parameters for functions

[Stephen Leake]

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

> Stephen Leake wrote:
> 
> > > 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 :).
> 
> "Random" is very special case, in which an intention is quite
> opposite to what is common in normal "regular" circumstances. 

Ok, fine. What is wrong with using mode "in out" for functions in
special cases?

-- 
-- Stephe

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Stephen Leake wrote:

> What is wrong with using mode "in out" for functions in special cases?

Nothing wrong, I think (especially if mutable parameters are marked as such
at the call site). But this thread was about the difference between IN OUT
and change of a global variable, and I just tried to show that this difference
really exists. It does not mean that I'm against IN OUT mode parameters for
functions. On the contrary, I think that it should be permitted (with suitable
restrictions and rules). But at the same time I think that arguments against
that must be stated explicitly.





Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> > "Random" is very special case
>
> So is any function which reads data from an external source,
> so it's not quite as special as you would have us believe.
No, I was answering for the case where Ada's standard function assumes (or
requires) that behaviour. But Ada's standard Get (in Ada.Text_IO) is not
a function, it is a procedure.

> It would be nice to be able to say (in my pidgin Ada)
>	Point p := (x => get(), y => get(), z => get());
> and know that the members would be read in the order given,
> not in some arbitray order.
If you want really nice programming environment of this kind, you probably
should try APL.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> If you want really nice programming environment of this kind, you probably
> should try APL.

Huh? I'm pretty sure I got the syntax wrong, but I was just using
an aggregate. I don't need APL just to use aggregates!

Re: In-Out Parameters for functions

[Stephen Leake]

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

> Stephen Leake wrote:
> 
> > What is wrong with using mode "in out" for functions in special cases?
> 
> Nothing wrong, I think (especially if mutable parameters are marked
> as such at the call site). But this thread was about the difference
> between IN OUT and change of a global variable, 

Hmm. Please see the "subject" line up above. If you beleive the
subject has changed, please post with a different subject.

> and I just tried to show that this difference really exists. 

Hmm. I guess there might be some subtle differences, but I don't see
them as important.

> It does not mean that I'm against IN OUT mode parameters for
> functions. On the contrary, I think that it should be permitted
> (with suitable restrictions and rules). But at the same time I think
> that arguments against that must be stated explicitly.

Ok, sounds like we are in agreement. Except I don't see any need for
any restrictions; that's what style guides and code reviews are for.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 27 Jan 2004 15:06:57 -0500, Robert A Duff
<bobduff@shell01.TheWorld.com> wrote:

>On the other hand, I suspect that order-changing optimizations are not
>really all that important for speed.

For example:

for I in A'Range loop
   Sum := Sum + A (I) + B (I - A'First + B'First);
end loop;

without order changing one cannot factor out the loop constant
(B'First - A'First). Should the programmer take care of that?

As a programmer I like to hand that stuff over to you, a compiler
designer. In case, I will always have an abilitity to blame that
"stupid compiler"! (:-))

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

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 27 Jan 2004 23:48:58 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Stephen Leake wrote:
>
>> > 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 :).
>
>"Random" is very special case, in which an intention is quite opposite to what
>is common in normal "regular" circumstances. In "regular" circumstances we want
>the same result

And we have the *same* result, a realization of a *random* number. It
indeed does not depend on the input parameters (ideally). A program
using random numbers in turn becomes random in the sense that its code
and results are random. So we could treat Random as a constant, in a
random program. Of course Random is pseudo random, so it needs a
parameter, which is an implementation detail.

BTW, amusing A.5.2:

   procedure Reset (Gen : in Generator);  -- Reset an *IN* parameter!

but consistent with the design choice. Interestingly, that a true
Random, taking numbers from a hardware, should indeed have "in
Generator", provided, that it does not destroy the hardware just by
reading the values. (:-))

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

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccfze1z4mm.fsf@shell01.TheWorld.com>...
> Peter Amey <peter.amey@praxis-cs.co.uk> writes:
> 
> >... SPARK functions never have side effects, ...
> 
> SPARK is consistent.  No side effects involving globals, no side effects
> involving parameters.  No side effects.  Simple.

But would you embark on writing, for example, a high performance email
server in SPARK?

> Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> so long as you don't document them on the function spec.

Looks to me like the ARG is far from agreement on this subject :-)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> for I in A'Range loop
>    Sum := Sum + A (I) + B (I - A'First + B'First);
> end loop;

For code like this, I would expect the compiler to be
generating all sorts of induction variables. There's
never going to be a loop constant to hoist. The
generated code should look something like this (in C):

n = A_Last - A_First + 1;
if (B_Last - B_First + 1 < n) raise Program_Error;
pa = &A[A_First];
pb = &B[B_First];
while (n-- > 0) sum += *pa++ + *pb++;

In any case, the compiler would be free to rearrange its
calculations any way it likes as long as the results are
the same as doing them in the proper order. If the compiler
cannot determine that this is the case, then the code is
probably tricky enough such that doing it in the defined
order is helpful.

Re: In-Out Parameters for functions

[Robert A Duff]

wojtek@power.com.pl (Wojtek Narczynski) writes:

> > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> > so long as you don't document them on the function spec.
> 
> Looks to me like the ARG is far from agreement on this subject :-)

That's true.  Tucker and I, for example, have had this argument several
times.  I'm in favor of allowing 'in out' parameters on functions in Ada
(but not SPARK!), and Tucker is against.

- Bob

Re: In-Out Parameters for functions

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccptd3olj2.fsf@shell01.TheWorld.com...
> wojtek@power.com.pl (Wojtek Narczynski) writes:
>
> > > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
> > > so long as you don't document them on the function spec.
> >
> > Looks to me like the ARG is far from agreement on this subject :-)
>
> That's true.  Tucker and I, for example, have had this argument several
> times.  I'm in favor of allowing 'in out' parameters on functions in Ada
> (but not SPARK!), and Tucker is against.

Which goes to show that even bright people can be wrong from time-to-time.
:-)

This topic is almost a religious war. I'm one of the few who's changed sides
(even though allowing 'in out' on functions would be such a disruptive
change to Janus/Ada that it probably would lead to the abandonment of the
technology), because it is impossible to do good (pointer-less) O-O
programming without it.

                           Randy.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 28 Jan 2004 10:20:37 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> for I in A'Range loop
>>    Sum := Sum + A (I) + B (I - A'First + B'First);
>> end loop;
>
>For code like this, I would expect the compiler to be
>generating all sorts of induction variables. There's
>never going to be a loop constant to hoist. The
>generated code should look something like this (in C):
>
>n = A_Last - A_First + 1;
>if (B_Last - B_First + 1 < n) raise Program_Error;
>pa = &A[A_First];
>pb = &B[B_First];
>while (n-- > 0) sum += *pa++ + *pb++;

This violates the evaluation order. It should be:

sum += *pa++;
sum += *pb++;

risking to overflow (*) and less stable numerically.

>In any case, the compiler would be free to rearrange its
>calculations any way it likes as long as the results are
>the same as doing them in the proper order.

You managed to factor (I - A'First) out, this can be done without
changing the evaluation order, fine. But what will you do for:

for I in A'Range loop
   Sum := Sum + A (I) + B (I + B'First - A'First);
end loop;

>If the compiler
>cannot determine that this is the case, then the code is
>probably tricky enough such that doing it in the defined
>order is helpful.

My point is, I would leave that stuff to the compiler developers. I
trust them more than me and my programmers! (:-))

----
* and reviving the discussion about introducing ":+="

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

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 28 Jan 2004 17:13:10 -0600, "Randy Brukardt"
<randy@rrsoftware.com> wrote:

>"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>news:wccptd3olj2.fsf@shell01.TheWorld.com...
>> wojtek@power.com.pl (Wojtek Narczynski) writes:
>>
>> > > Ada is inconsistent -- as Robert Dewar says, side effects are allowed,
>> > > so long as you don't document them on the function spec.
>> >
>> > Looks to me like the ARG is far from agreement on this subject :-)
>>
>> That's true.  Tucker and I, for example, have had this argument several
>> times.  I'm in favor of allowing 'in out' parameters on functions in Ada
>> (but not SPARK!), and Tucker is against.
>
>Which goes to show that even bright people can be wrong from time-to-time.
>:-)
>
>This topic is almost a religious war. I'm one of the few who's changed sides
>(even though allowing 'in out' on functions would be such a disruptive
>change to Janus/Ada that it probably would lead to the abandonment of the
>technology), because it is impossible to do good (pointer-less) O-O
>programming without it.

Would not procedures with return be a minor, non-obtrusive change?

I am afraid that allowing IN OUT parameters would be inconsistent with
the functions of the protected objects. Provided that the prefix
notation creeps Ada, it will be difficult to explain when X.Foo may
change X and when not.

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

Re: In-Out Parameters for functions

[Peter Amey]

Wojtek Narczynski wrote:
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in message news:<wccfze1z4mm.fsf@shell01.TheWorld.com>...
> 
>>Peter Amey <peter.amey@praxis-cs.co.uk> writes:
>>
>>
>>>... SPARK functions never have side effects, ...
>>
>>SPARK is consistent.  No side effects involving globals, no side effects
>>involving parameters.  No side effects.  Simple.
> 
> 
> But would you embark on writing, for example, a high performance email
> server in SPARK?
> 

Possibly (or possibly not); however, the absence of function side 
effects would not be a factor in that decision.  Probably the biggest 
obstacle might be the desire to use dynamic data structures constructed 
with access types (which SPARK does not support).

Peter

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> Which goes to show that even bright people can be wrong from time-to-time.
> :-)

It is not a problem, as long as they are able to admit it.

> This topic is almost a religious war.

Too bad...

> I'm one of the few who's changed sides (even though allowing 'in out' on
> functions would be such a disruptive change to Janus/Ada that it probably
> would lead to the abandonment of the technology), (...)

Sounds hard to believe, but as I look at your email, I believe you.
How about you add 'return' and 'access' to procedures instead?
(Probably a silly question)

Regards,
Wojtek

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> My point is, I would leave that stuff to the compiler developers. I
> trust them more than me and my programmers! (:-))

It's precisely because people make mistakes that you want a
line of code to always mean the same thing. Otherwise, you
can wind up with something that has unspecified behavior but
happens to do what you want on a given platform, and then it
is liable to break with changes in compiler, or system, or
level of optimization, or being looked at funny.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 29 Jan 2004 10:37:27 -0500, Hyman Rosen wrote:
> It's precisely because people make mistakes that you want a
> line of code to always mean the same thing. Otherwise, you
> can wind up with something that has unspecified behavior but
> happens to do what you want on a given platform, and then it
> is liable to break with changes in compiler, or system, or
> level of optimization, or being looked at funny.

Why should buggy code work? If I wanted buggy code to work, I could use a
programming language that has silent overflow and no array bounds
checking. You can actually get away with that often. But Ada is there to
help me produce correct, maintainable code. Mandating the order of
evaluation doesn't make the code more maintainable, or most likely more
correct. If a programmer realizes what they're doing, at the very least
they can put f(x) and g(x) on separate lines to show that the order
dependency. If they don't realize what they're doing, half the time 
g(x) + f(x) would have been the right code to use.

Re: In-Out Parameters for functions

[Hyman Rosen]

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

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: In general, the compiler cannot know whether particular
: code has such order dependencies or not, and so cannot reliably
: warn of such uses.

True, however in general, i.e. in the presence of global state,
a _programmer_ cannot know what the results of evaluating
expressions in order will be. A reason is complexity of the
required reasoning, in particular in the presense of tasking.


-- Georg

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Wojtek Narczynski wrote:

>How about you add 'return' and 'access' to procedures instead?
At this point I can't resist the temptation to quote my own posting to
Ada-Comment (November 2002) along with the brief discussion, which followed
(I removed the poster's name from all replies). Here it is:

=============================================================================
I'm not going to restate the arguments, but just want to know what is bad or
wrong in the following solution for a problem:

----------
Let us introduce new mode for formal parameter: RETURN mode. This RETURN mode
is the same as OUT mode except the following rules:

  in the procedure specification:

    1) only the first parameter of the procedure may be in RETURN mode;
    2) IN mode is incompatible with RETURN mode, that is, there is no IN RETURN
       mode.

  in the procedure body:

    if the formal parameter in RETURN mode is of indefinite type then the
    attributes, which depend on undefined properties (for example, 'First,
    'Length, etc.) cannot be used for that parameter.

  in a procedure call:

    1) a procedure with the first parameter in RETURN mode may be invoked as
       function (without argument for the first parameter);
    2) normal (that is, procedural) call for that procedure is also available;
       in that call RETURN mode is treated as OUT mode.

----------

--------------------------------------------------------------------------

This is a warmed over version of the DEC Valued_Procedure pragmas ...

--------------------------------------------------------------------------

>This is a warmed over version of the DEC Valued_Procedure pragmas ...

Well, of course, and GNAT implements those pragmas also. But this similarity
is a good thing, as it certifies for a proven mechamism. The difference is that
it is not an implementation-defined pragma(s), but a straight language form.

--------------------------------------------------------------------------

> Well, of course, and GNAT implements those pragmas also. But this similarity
> is a good thing, as it certifies for a proven mechamism. The difference is that
> it is not an implementation-defined pragma(s), but a straight language form.


Well I regard both the pragmas and the AK proposed substitute as too junky
to consider. If you want IN OUT parameters for functions, just allow them.
The DEC pragmas are merely a kludgy device to get around the absence of
a needed feature. I don't see the AK proposal here as any improvement over
the pragmas.

--------------------------------------------------------------------------

> Let us introduce new mode for formal parameter: RETURN mode.
> This RETURN mode is the same as OUT mode except the following rules:
>...

This basic idea might serve as a solution to the "constructor function"
problem that Bob Duff is working in AI-318. The problem with the existing
proposals for that were that the methods of getting a name for the return
result were just plain weird - objects with boatloads of restrictions. It
may be easier to define the needed restrictions in terms of a parameter
mode.

...
--------------------------------------------------------------------------
=============================================================================

Hope this helps -;) .



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> True, however in general, i.e. in the presence of global state,
> a _programmer_ cannot know what the results of evaluating
> expressions in order will be. A reason is complexity of the
> required reasoning, in particular in the presense of tasking.

What a puzzling statement! If a programmer cannt reason about
     c := f1 + f2;
even knowing that f1 and f2 will be called left-to-right, how
can he reason about
     a := f1;
     b := f2;
     c := a + b;

Re: In-Out Parameters for functions

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:6fjh109qllmjek7ud2me7k1t40so3ervmk@4ax.com...
> On Wed, 28 Jan 2004 17:13:10 -0600, "Randy Brukardt"
> <randy@rrsoftware.com> wrote:
>
...
> >This topic is almost a religious war. I'm one of the few who's changed
sides
> >(even though allowing 'in out' on functions would be such a disruptive
> >change to Janus/Ada that it probably would lead to the abandonment of the
> >technology), because it is impossible to do good (pointer-less) O-O
> >programming without it.
>
> Would not procedures with return be a minor, non-obtrusive change?

No. The problem with Janus/Ada's intermediate code is that it assumes that
all calls that return results (and thus can occur in expressions) do not
require parameter checking after the call, and thus does not allow access to
those parameters. In particular, there is nowhere to hang those checks
(called "moss" in the terminology Dan Stock invented to explain our
optimizer; "moss" because it hangs on a tree but isn't part of it.) In
addition, it doesn't allow parameters to be left on the stack after a
value-returning call (which also causes trouble with C varargs functions,
but that is a very limited and very rare problem). We could get around some
of the problems by using a different calling convention for function calls
(passing all in-outs by reference, for instance, making a local copy at the
call site), but that would complicate all kinds of code -- currently,
parameter passing doesn't depend on the entity to which it is passed.

There would be no difference between a procedure returning a value and a
function returning a value to the intermediate (and eventually machine)
code. As such, I don't see much value in that.

                      Randy.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 29 Jan 2004 14:46:22 -0500, Hyman Rosen wrote:

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

Actually, I do understand that.

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

That's true, and not unique to this case. Not taking care of the size of
Integer or integers can cause the same problem. So can threading code. 

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

The difference is that with array bounds or pointer access, the compiler
stops and says you're doing something wrong. This is more analogues to
making array accesses silently wrap to prevent out of bound access; it may
be what the programmer wanted, but a lot of times it won't be, and it will
confuse maintainers who come afterwards.

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

I don't think 

a := f(x);
b := g(x);
c := a + b;

is much better than

c := f(x) + g(x);

if f(x) and g(x) make silent changes to significant global state. But
the first at least makes some indication that the order of operations is
important. This is not proper coupling; I hardly see why Ada should go out
of its way to support bad, unmaintainable code.

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

I don't think it is. I don't really approve of the second statement,
either. In any case,
  for I := 0.0 .. 2.0 step 0.25 loop
could also be considered perfectly sensible, but most of the statements
that extension would let in wouldn't be considered sensible.

Re: In-Out Parameters for functions

[Robert I. Eachus]

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

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> will be caught by the SPARK toolset...
 > establish guidelines...

To be caught by a toolset requires whole-program analysis.
At the very least, this dooms people who are writing libraries
or generics. Establishing guidelines is no substitute for having
the language avoid problems. C has a guideline that you should
not index beyond the end of an array.

> To change the rules now would make lots of code obsolete.

How can defining something which was previously unspecified
make code obsolete? I'm not saying that Ada should change
any specified behavior it currently has, I'm just saying
that currently unspecified behavior should become specified.

> Now think about the effort required to develop the tools
 > for your proposed change, and go away.

There's certainly work involved in the compiler to make it
evaluate things in a specific order. I personally would not
classify it at the "go away" level. I know that GCC includes
a Java compiler, so it at least has infrastructure for doing
this at some level.

Re: In-Out Parameters for functions

[Peter Amey]

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
>> will be caught by the SPARK toolset...
> 
>  > establish guidelines...
> 
> To be caught by a toolset requires whole-program analysis.
> [snip]

Not so in the case of SPARK.  The language design and the use of 
annotations means we can find things like function side effects and 
aliasing at the program unit level using computationally efficient 
techniques.  We can frequently find errors in programs that are not yet 
complete enough to compile.  That is why SPARK users typically run the 
Examiner about 10 times as often as they run the compiler (and about a 
million times as often as they run the debugger!).

See http://www.sparkada.com/downloads/sigada2001.pdf for an overview of 
how this all works.

Peter

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 >>it is perfectly legal to write code which has unspecified results
 >>due to order of execution.
> 
> Wrong. Here is ARM 4.5: 
> allowed result /= unspecified result

That very same section says that
     The two operands of an expression of the form X op Y,
     where op is a binary operator, are evaluated in an
     arbitrary order, as for any function_call

arbitrary order = unspecified result

If I have (pidgin Ada again!)
     x : 0..1 := 0;
     function f : integer is begin x := 1 - x; return x; end f;
     r : integer := f - f;
Then Ada legally permits r to be 1 or -1. That's what I call
unspecified, i.e., no single result is required. In a particular
fixed environment, it is likely that the above code will always
return the same value. If this is done in production code rather
than in a contrived example, and the order dependency isn't so
apparent, it will seem that everything is fine. Then a change in
environment can make the opposite result appear, and things may
be broken.

Everyone here is saying "so don't do that", which is what we
C/C++ programmers always say, and which you Ada guys sneer at.

> Do you really believe that tests will detect an "incorrect" order
 > when specified by RM more probably than when selected by the compiler?

I believe that once code is written, tested, and found to work, then
having the evaluation order chosen by the language means that it will
continue to work even when the environment changes. If the order is
selected by the compiler, then you have no such assurance. Surely
this is obvious?

> In my experience errors like this are extremely difficult to detect

With a defined rather than arbitrary order, this might no longer be
an error. Removing sources of uncertainty in the language is good.

> Both under- and overspecification are wrong.

Nevertheless, in conventional programming languages overspecification
is the rule, and it is what programmers are used to. It is left to the
compiler to rearrange things if it can prove that the result remains
correct by the rules of the language, just as in the section you quoted.

>>    cx, cy, cz : Coord := ReadCoord;
> I presume here the order is also arbitrary.

No, it is not. See 3.3.1/7. The order is strictly left-to-right.

> 50% of them would believe that keyed associations will not override the
 > native order of record fields.

I don't believe that for a second. Making up dumb statistics in order
to bolster an untenable position is silly.

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

Yes, actually I very much think so, and there should be no guessing involved.

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> True, however in general, i.e. in the presence of global state,
:> a _programmer_ cannot know what the results of evaluating
:> expressions in order will be. A reason is complexity of the
:> required reasoning, in particular in the presense of tasking.
: 
: What a puzzling statement! If a programmer cannt reason about
:     c := f1 + f2;
: even knowing that f1 and f2 will be called left-to-right, how
: can he reason about
:     a := f1;
:     b := f2;
:     c := a + b;

He can't. Order won't help unless you assume that order
eases predicting the current global state and how it interacts
with f1 and f2 (or f2 and f1).

Thus order might help in some circumstances, however I don't see
the really big help it offers.

Re: In-Out Parameters for functions

[David Starner]

On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen wrote:
> If I have (pidgin Ada again!)
>      x : 0..1 := 0;
>      function f : integer is begin x := 1 - x; return x; end f;
>      r : integer := f - f;
> Then Ada legally permits r to be 1 or -1. That's what I call
> unspecified, i.e., no single result is required. In a particular
> fixed environment, it is likely that the above code will always
> return the same value. If this is done in production code rather
> than in a contrived example, and the order dependency isn't so
> apparent, it will seem that everything is fine. Then a change in
> environment can make the opposite result appear, and things may
> be broken.
> 
> Everyone here is saying "so don't do that", which is what we
> C/C++ programmers always say, and which you Ada guys sneer at.

Everyone uses arrays and pointers. They are a part of good code. So
Ada people sneer about people who ignore problems even good
programmers have. They don't sneer about unmaintainable code (because "the
order dependency isn't [...] apparent") that they could make deterministic
at the cost of good code. What happens when someone uses f-f later
assuming it will be 1? Or if someone changes the code not to call f-f and
fails to make the side effects that something else is depending on? This
is bad code, and needs to be fixed at the program level, not the language
level.

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> Thus order might help in some circumstances, however I don't see
> the really big help it offers.

As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
     Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
just as
     cx, cy, cz : Coord := ReadCoord;
works. But the really big help is that the meaning of such code won't
silently change when changing some aspect of the environment. Of what
benefit is it to the programmer when the ARM allows things to happen
in arbitrary order?

Re: In-Out Parameters for functions

[Hyman Rosen]

Peter Amey wrote:
>> To be caught by a toolset requires whole-program analysis.
> 
> Not so in the case of SPARK.

As far as I know, SPARK has no way of calling procedures
except by explicitly mentioning their names. That is, there
are no procedure access variables, no generics, and no
dispatching. So it's no surprise that when you annotate a
declaration in enough detail to tell you what the body will
be doing, you can perform the analysis without seeing the
body. That's close to whole-program analysis in my book.

Also, SPARK doesn't allow side-effects in functions, so this
discussion is pretty moot from SPARK's point of view.

But Ada is not SPARK. Ada does have procedure access variables,
generics, dispatching, and side-effects, and the issues of
evaluation order are germane.

By the way, I read the paper to which you referred. What happens
in SPARK if I have
     package Sensor
     --# own in State;
     is
         function Value return Integer;
         --# global State;
     end Sensor;
and I try to write
     delta : Integer := Sensor.Value - Sensor.Value;

Can I write a function, not a procedure, which will return
different sensor values each time? Can I use them multiple
times in an expression?

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> Thus order might help in some circumstances, however I don't see
:> the really big help it offers.
: 
: As I have said, it makes some "obvious" uses work unsurprisingly, eg.,
:     Point p := (x => ReadCoord, y=> ReadCoord, z => ReadCoord);
: just as
:     cx, cy, cz : Coord := ReadCoord;
: works. But the really big help is that the meaning of such code won't
: silently change when changing some aspect of the environment. Of what
: benefit is it to the programmer when the ARM allows things to happen
: in arbitrary order?

(add  p: Point := (x | y | z => ReadCoord); to the list of surprises.)

People coming from the substitution model of programming might
"feel like they know what's going on" (L. Wall, perlmod),
however this might be the opposite of helpful in writing
programs that use assignment not substitution, or that use "world",
with or without order.

It matches the tasking dizziness well.

But I won't insist, I'm only trying to see how this could make sense.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
 > They don't sneer about unmaintainable code that they
 > could make deterministic at the cost of good code.

The example I have previously posted,
     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not "unmaintainable", except that it is non-deterministic in
current Ada. On the other hand, the following code
     cx, cy, cz : Coord := ReadCoord;
     p : Point := (x => cx, y => cy, z => cz);
is perfectly deterministic. Is it unmaintainable? Perhaps. But the
point is that someone might innocently code the first case, most
likely in a less obvious way, and it might survive all checking
and testing, because such things do, just like buffer overflows
stay in C/C++ code. The "cost" to good code is a phantom, trotted
out as an excuse for maintaining the status quo.


> What happens when someone uses f-f later assuming it will be 1?

With a defined order of execution, if it wasn't 1 before it wouldn't
be 1 now, and the tests would fail, demonstrating the error to the
programmer. With an arbitrary order of execution, it will turn out
to be 1 in the debug build and -1 in the production build, returning
the wrong answer at the worst possible time.

> Or if someone changes the code not to call f-f and fails to make
 > the side effects that something else is depending on?

Then the code will fail, and testing will show that it has failed.

> This is bad  code, and needs to be fixed at the program level,
 > not the language level.

Whether or not the code is bad, I believe that it can readily slip
through checks into production because it works by coincidence. It
cannot be fixed at the program level any more than array overflows
can be fixed at the program level.

Re: In-Out Parameters for functions

[Hyman Rosen]

Georg Bauhaus wrote:
> People coming from the substitution model of programming...
> I'm only trying to see how this could make sense.

I'm trying to see how someone could believe that fixing an order of
evaluation doesn't make sense. Of what use is arbitrariness to the
semantics of the language?

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> I believe that once code is written, tested, and found to work, then
> having the evaluation order chosen by the language means that it will
> continue to work even when the environment changes. If the order is
> selected by the compiler, then you have no such assurance. Surely
> this is obvious?

You must be surprised, but the right answer is "generally, NO". The situation
depends on kind of applications for which the language is aimed.

When you rely upon fixed (in the language) evaluation order you are risking
to make things non-commutative. And if those things are commutative in the
underlying theory then you are subjected to unexpected failure when some part
of your "environment" changes. And if evaluation order is fixed in the
language then you lose an opportunity to caught that potentially dangerous
non-commutativity by testing with various compilers and various optimization
levels. Moreover, those failures that happen because of this difference -
between a theory, which is based on commutativity, and a non-commutative
implementation, may be extremely hard to investigate, just because the reason
is located neither in theory nor in software implemention, but somehow between
them. So, by fixing order of evaluation you enhance the overall situation
for theoretically trivial applications, but worsen it for applications that
are substantially based on non-trivial mathethical/physical theories.

So, both decisions - to fix evaluation order in Java and not to do that in Ada
- are right, these languageas are extreme cases: Java is used primarily for
theoreticaly trivial applications, while Ada is often used for applications,
based on mathematically non-trivial theories.

> Nevertheless, in conventional programming languages overspecification
> is the rule, and it is what programmers are used to.

That's true about commodity, but Ada language too often is used for programming
things that aren't commodities in any reasonable sense, and this is Ada's
native land. Ada isn't a popular language, can't be, and don't strive to be
too popular; what is desired is to get as much as possible of proper audience,
but not much more.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Georg Bauhaus]

Hyman Rosen <hyrosen@mail.com> wrote:
: Georg Bauhaus wrote:
:> People coming from the substitution model of programming...
:> I'm only trying to see how this could make sense.
: 
: I'm trying to see how someone could believe that fixing an order of
: evaluation doesn't make sense. Of what use is arbitrariness to the
: semantics of the language?

I had people in mind, not just programming languages.
You might say it makes sense to adapt one's reasoning to the
requirements of a programmaing language/style etc.
For predicting properties of object code this might be necessary
in addition to checking. However, do you define or design high
level languages to just produce object code in a systematic
manner or is there more to it? Like expressiveness, dealing well
with what people (not: Scheme fans, Ada fans, APL fans)
usually do when writing programs? Languages that suggest
ways of commanding a computer to "execute an idea"?

In the substitution model you don't have to worry about
the order of evaluation, that is, you reduce complexity.
However, the world has state, and no rollback, so the 
substitution model may not work.

Consequence: In the presence of time dependence, learn to
"think from left to right" in addition to down the sequence
of instructions.
Alternative consequence: In the presence of time dependence, if you
want a specific order of elaboration, say so in the direction
of declarations and statements, but not when it comes to
"inputs" to "value creating items". (I admit that this is somewhat
artificial.)

If you say that the idea of substitution should not be a guideline
when variables can have changing values, you might want order of
evaluation to imply consistency with western wrinting direction in all
respects. I.e. I am weighting other aspects of source code constructs
less, like "a collection of inputs to a function where each
input is named" --conceptually the order of association is an addon
necessitated by that nasty time dependent statefulness of the world
in case there are globals or inputs or side effects.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Dmitry A. Kazakov wrote:

> I am afraid that allowing IN OUT parameters would be inconsistent with
> the functions of the protected objects. Provided that the prefix
> notation creeps Ada, it will be difficult to explain when X.Foo may
> change X and when not.

If we require a mark for IN OUT parameter at call cite, that is,

  F(keyword X)

then X.F will be illegal (given that

   keyword F.X

is illegal).




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> I'm trying to see how someone could believe that fixing an order of
> evaluation doesn't make sense. Of what use is arbitrariness to the
> semantics of the language?

This has been explained once in this thread, but here goes again.  The 
order of evaluation that Ada allows to be arbitrary is so that some 
'common' optimizations such as common subexpression elimination and code 
hoisting can be done.  This trade-off was explicitly accepted because 
without it, much of the constraint checking that Ada requires would be 
too expensive, and everyone would turn it off.  (In fact, in the 
embedded world we often had to convince project management not to 
mandate turning constraint checking off.  It does no good for the 
programmers to know that Ada constraint checking is essentially cost 
free if you don't explain that to management as well.)

Let me give a simple example to explain this:

for I in A'Range loop
   A(I) := B(I);
end loop;

Now 'obviously' you don't have to do the range check on A every time 
through the loop, but what about B?  You can check that the lower bound 
is okay once, but it seems that you have to check against the upper 
limit each time.  Actually in Ada 95, you don't.  I won't go into the 
ramifications needed to explain this hear, because the real explanation 
is that the programmer didn't ask for it, and we don't want to prevent 
the compiler from handling this move the same way as:

  A := B(A'First..A'Last);

If you really NEED the check to be repeated, write:

for I in A'Range loop
   begin
     A(I) := B(I);
   exception
     when Constraint_Error => Do_Something(I);
   end;
end loop;

If A and B are Strings, you should now get a byte copy and the value of 
I in the exception handler will reflect the first subscript to fail the 
check.

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

(Others have done a good job of answering most of Hyman's points, but...)

>> To change the rules now would make lots of code obsolete.

> How can defining something which was previously unspecified
> make code obsolete? I'm not saying that Ada should change
> any specified behavior it currently has, I'm just saying
> that currently unspecified behavior should become specified.

Your assumption is that you could create a new rule which makes the new 
language a subset of the old one.  In one sense, that is easy.  Keep all 
the old legality rules and just add new ones.  Some existing programs 
will no longer compile, but if they do compile, they will have the same 
semantics as before.  I don't think you can come up with a set of rules 
like that without a lot of effort, but you are welcome to try.  The 
SPARK people certainly took that path and did it successfully.

But what if you keep the legality rules the same, and "just" change the 
semantics?  Then the problem is proving that existing code will have the 
same semantics under the new rules as under the old ones.

The current situation is that order of evaluation in Ada is partially 
specified.  I know of lots of code which was validated in part "by hand" 
and in part by tools which recognize the current Ada rules.  If the 
semantics change, recompiling this code makes all that analysis junk. 
(For example, red/black analysis in crypto code.)

If you want to reuse the existing code with new code, it is impractical 
to redo that analysis. (The code is often written so as to make the 
analysis easier.  But it won't necessarily be that easy for the new 
semantics.) So you either use a "project validated" compiler, or throw 
the code away.

I know what I would do, and changes in Ada that would make using "new" 
Ada compilers an issue are just what I said, a non-starter.

Notice that I and many other programmers know the existing Ada rules 
very well, and so does the SPARK Examiner.  That is one measure of how 
much would be thrown away by a major change to 11.6.

Incidently Ada 95 did change 11.6.  But it is worth noting that the 
changes were to resolve AI-315--remember that is an Ada 83 AI 
number--which we never found a fix for that wouldn't do too much damage 
to the language and to compilers.  Since Ada 95 was a much bigger change 
than Ada 0Y will be, we accepted that change then.  But not without a 
lot of soul searching.  It may have been that more soul-searching would 
have been worthwhile.  (The change is to define canonical semantics in 
terms of external effects.)  See 11.6(3) and 1.1.3(8-15).  In fact, I 
think that one change did more to slow the adoption of Ada 95 than any 
other change from Ada 83.

> There's certainly work involved in the compiler to make it
> evaluate things in a specific order. I personally would not
> classify it at the "go away" level. I know that GCC includes
> a Java compiler, so it at least has infrastructure for doing
> this at some level.

Once again, the problem is not with the compiler.  The whole idea of the 
entire HOLWG effort, even before GREEN became Ada, was to reduce the 
number of programming languages and compilers used by the DoD so that an 
infrastructure of support tools could be built around one or more core 
languages.  The HOLWG then decided that no existing language was 
sufficient as a base language for embedded system programming and tools. 
  That started a process that ended up creating Ada.

SPARK is one of the few non-compiler Ada tools that has reached the 
necessary critical mass to be able to say that it won't go away.  Other 
tools are part of the support infrastructure for each compiler, and 
should last at least as long as the compiler does.  An example in this 
category is gnatchop.  There are lots of other tools, such as GtkAda 
that have not reached the plateau, but if Ada usage keeps growing they 
will get there.  Or you can consider Rational's tools.  Rational made a 
business decision to develop those tools for several languages, 
primarily C++ and Ada. It might be interesting to find out what the 
relative sizes of the Ada and C++ markets are for Rational's tools, but 
from the original HOLWG viewpoint, it is irrelevant.  The tools are 
commercial, and the tools are available.  Anything else is gravy.


So in my opinion, any change to Ada which had the effect of invalidating 
  existing toolsets is a non-starter--and a bad idea.

Incidently there is nothing preventing anyone reading this from getting 
the GNAT compiler source and modifying it to support, say, in out 
parameters for functions.  But if you want to try a major change like 
the one Hyman is suggesting, I know I wouldn't have the energy or 
patience to try it.  A change like in out parameters for functions is 
localized, and even thought the localization may only be to a dozen 
places in the code, it shouldn't require modifying more than 5 KSLOC. 
Changing the order of evaluation rules would affect a substantial 
fraction of the entire compiler.  Call it reviewing 500 KSLOC and 
modifying 100 KSLOC.  Put out an RFP and I'll "No bid."  ACT might 
respond. ;-)


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

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1075482385.142744@master.nyc.kbcfp.com...
...
> That very same section says that
>      The two operands of an expression of the form X op Y,
>      where op is a binary operator, are evaluated in an
>      arbitrary order, as for any function_call
>
> arbitrary order = unspecified result

Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
and that's what people here (usually) mean. "Unspecified" means not only is
*any* result allowed, but also that the implementer doesn't even need to
tell you what the result will be. "Implementation-Defined" is that any
result is allowed, but the implementer has to tell you which it is.

This case is "only" about a (usually small, often a singleton) set of
allowed results. In your example, returning "-2" isn't allowed (obviously).

I realize you are using the term informally, but I think you're confusing a
lot of people by using it.

                  Randy.

Re: In-Out Parameters for functions

[cl1motorsports]

i just started on this message, and i don't know ada very well, BUT
wouldn't the best solution be to have the compiler throw an error if a
parameterless function that returns a different value is used as a
parameter to a procedure or function call? It is
bad form to write code like that in the first place.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> Sorry, Hyman, but Ada has a very specific meaning for "unspecified result",
> and that's what people here (usually) mean. "Unspecified" means not only is
> *any* result allowed, but also that the implementer doesn't even need to
> tell you what the result will be.

That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
     Certain aspects of the semantics are defined to be either
     implementation defined or unspecified. In such cases, the
     set of possible effects is specified, and the implementation
     may choose any effect in the set. Implementations shall document
     their behavior in implementation-defined situations, but
     documentation is not required for unspecified situations.

So I would have to say you're wrong. Unspecifed behavior allows the
implementation to choose from a limited set of possible effects, not
from an unlimited one, and the implementation doesn't have to tell
you what it chooses.

 > I realize you are using the term informally, but I think you're confusing a
 > lot of people by using it.

Apparently, I was using it formally, and the confused people are confused :-)

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
 > And if evaluation order is fixed in the language then you lose an opportunity
 > to caught that potentially dangerous non-commutativity by testing with various
 > compilers and various optimization levels.

I'm sorry, but this is abject nonsense. When you use a language that does not
specify evaluation order and does not require the implementation to document
evaluation order, you will gain absolutely zero knowledge about "dangerous
non-commutativity" whatever the heck that might even mean, no matter how much
testing you do on how many systems, becaus eyou have no way of knowing if any
of those systems did their evaluations in an order different from another.

> So, both decisions - to fix evaluation order in Java and not to do that in Ada
> - are right, these languageas are extreme cases: Java is used primarily for
> theoreticaly trivial applications, while Ada is often used for applications,
> based on mathematically non-trivial theories.

This is so nonsensical, it approaches the level of the Chewbacca defense.
You may choose to believe this if you like, and I won't even attempt to
argue with this line of reasoning. It would be like debating the mad.

Re: In-Out Parameters for functions

[David Starner]

On Sun, 01 Feb 2004 04:10:37 +0000, Hyman Rosen wrote:

> When you use a language that does not
> specify evaluation order and does not require the implementation to document
> evaluation order, you will gain absolutely zero knowledge about "dangerous
> non-commutativity" whatever the heck that might even mean

You won't gain knowledge by brute force, but it does permit certain
reasoning, formal and informal, about code that you can't do if the
language forces evaluation order.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> You won't gain knowledge by brute force, but it does permit certain
> reasoning, formal and informal, about code that you can't do if the
> language forces evaluation order.

Sure. The compiler can say "I can pick an arbitrary order, so obviously
the programmer doesn't care what the order is." It's just like in C++,
where the compiler says, "He's using this as the index, so he must know
wht he's doing." If the programmer did thsi by intention, then an
opportunity for optimization is exposed. If the programmer is in error,
then an opportunity for a bug is exposed. The question is whether the
potential gain in optimization outweighs the potential for error. I don't
believe the potential for optimization afforded by leaving order of
execution unspecified is significant at all.

Re: In-Out Parameters for functions

[David Starner]

On Sun, 01 Feb 2004 21:55:54 +0000, Hyman Rosen wrote:

> David Starner wrote:
>> You won't gain knowledge by brute force, but it does permit certain
>> reasoning, formal and informal, about code that you can't do if the
>> language forces evaluation order.
> 
> Sure. The compiler can say "I can pick an arbitrary order, so obviously
> the programmer doesn't care what the order is." 

But the human can also say that. He doesn't have to worry that the
programmer before him, knowing the evaluation rules, make a+b /= b+a.

> It's just like in C++,
> where the compiler says, "He's using this as the index, so he must know
> wht he's doing." 

But Ada can do something about that. For this to be equivalent, you'd have
to be asking for Ada to always return 0 or A(A'First) if you used an index
out of range. 

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Fri, 30 Jan 2004 12:06:26 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> >>it is perfectly legal to write code which has unspecified results
> >>due to order of execution.
>> 
>> Wrong. Here is ARM 4.5: 
>> allowed result /= unspecified result
>
>That very same section says that
>     The two operands of an expression of the form X op Y,
>     where op is a binary operator, are evaluated in an
>     arbitrary order, as for any function_call
>
>arbitrary order = unspecified result
>
>If I have (pidgin Ada again!)
>     x : 0..1 := 0;
>     function f : integer is begin x := 1 - x; return x; end f;
>     r : integer := f - f;
>Then Ada legally permits r to be 1 or -1. That's what I call
>unspecified, i.e., no single result is required.

Does the specification of f require single result? It does not,
because f could as well call to Random or ask operator for a value.
Moreover, there could be a concurrent task modifying x! So it is not
Ada, but you who didn't specify it. Should you have written down the
full contract of f, a user of f would know whether it is legal to use
f as above, or concurrently from different tasks etc. The real [Ada]
problem is not order, but that a malignantly impure f can be used as
if it were pure.

>In a particular
>fixed environment, it is likely that the above code will always
>return the same value. If this is done in production code rather
>than in a contrived example, and the order dependency isn't so
>apparent, it will seem that everything is fine. Then a change in
>environment can make the opposite result appear, and things may
>be broken.

Which means that the code is wrong.

>Everyone here is saying "so don't do that", which is what we
>C/C++ programmers always say, and which you Ada guys sneer at.

OK, according to your theory C++ is right requiring to specify
parameter passing mode: by-copy vs. by-reference. But it is just one
of many evil features of C++! Once per month reviewing code I detect
programmers passing constant containers by copy! They do it over and
over again. Imagine a test which would catch that? With some
exemptions Ada leaves that to the compiler. And yes, it is well
possible to write a program which will work if the compiler chooses
one mode and crash otherwise.

>> Do you really believe that tests will detect an "incorrect" order
> > when specified by RM more probably than when selected by the compiler?
>
>I believe that once code is written, tested, and found to work, then
>having the evaluation order chosen by the language means that it will
>continue to work even when the environment changes. If the order is
>selected by the compiler, then you have no such assurance. Surely
>this is obvious?

It is not. Because "found to work" /= "found correct". There is a hope
that a code dependent on execution order will continue to work so far
the order is not changed. But isn't it better to know that the code
remains valid for any order?

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

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Sat, 31 Jan 2004 02:39:43 +0300 (MSK), "Alexandre E. Kopilovitch"
<aek@VB1162.spb.edu> wrote:

>Dmitry A. Kazakov wrote:
>
>> I am afraid that allowing IN OUT parameters would be inconsistent with
>> the functions of the protected objects. Provided that the prefix
>> notation creeps Ada, it will be difficult to explain when X.Foo may
>> change X and when not.
>
>If we require a mark for IN OUT parameter at call cite, that is,
>
>  F(keyword X)
>
>then X.F will be illegal (given that
>
>   keyword F.X
>
>is illegal).

Why should we do it at call site?

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

Re: In-Out Parameters for functions

[Peter Amey]

[snip]
> 
> By the way, I read the paper to which you referred. What happens
> in SPARK if I have
>     package Sensor
>     --# own in State;
>     is
>         function Value return Integer;
>         --# global State;
>     end Sensor;
> and I try to write
>     delta : Integer := Sensor.Value - Sensor.Value;

You get a static semantic error: SPARK only allows variables and 
constants to be initialized by constant (i.e. fixed at compile time) 
expressions.  Functions cannot be used.  (There are other reasosn for 
this as well including avoidance of elaboration order dependencies).

> 
> Can I write a function, not a procedure, which will return
> different sensor values each time? Can I use them multiple
> times in an expression?
> 

No.  There are special rules for volatile functions.  They can only be 
used directly in simple assignment or return statements, not in general 
expressions.

Peter

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Which means that the code is wrong.
 > ...
 > Because "found to work" /= "found correct".
 > ...
> But isn't it better to know that the code remains valid for any order?

There's no question that the code is wrong. There's no question that
as the language stands, it would be better to know that it is valid
for any order. The problem is that wrong code which has been found
to work can slip out into production. We know this is the case in C
for array bounds and pointer access, exacerbated by the compiler not
checking for these kinds of errors, and I don't see why it should not
be the case for Ada errors not detected by the compiler.

Once this code has slipped out into production, what gain is there by
having it potentially break by a change in environment?

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> But Ada can do something about that. For this to be equivalent, you'd have
> to be asking for Ada to always return 0 or A(A'First) if you used an index
> out of range. 

No, because in this case there is always a valid result to return,
since the results are merely unspecified (i.e., chosen from a legal
set of possible outcomes). Why do we want the compiler to pick an
arbitrary value instead of specifying which one it picks?

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 02 Feb 2004 09:33:21 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Which means that the code is wrong.
> > ...
> > Because "found to work" /= "found correct".
> > ...
>> But isn't it better to know that the code remains valid for any order?
>
>There's no question that the code is wrong. There's no question that
>as the language stands, it would be better to know that it is valid
>for any order. The problem is that wrong code which has been found
>to work can slip out into production. We know this is the case in C
>for array bounds and pointer access, exacerbated by the compiler not
>checking for these kinds of errors, and I don't see why it should not
>be the case for Ada errors not detected by the compiler.

It should be the case, but it does not imply fixing the order.
Semantically wrong code cannot be made correct by doing that. To
continue your analogy with bounds checks, it is like to allow wrong
array index, but to define the result of A [-99999999999] as 0. It is
not much better. Better is to check, which means checking for
order-dependent side effects.

Fixing and specifying does not solve the problem of knowing what and
how things are fixed. In C++ A & B | C is legal and specified, but I
do appreciate Ada for making A and B or C illegal.

>Once this code has slipped out into production, what gain is there by
>having it potentially break by a change in environment?

Wrong code should not go so far.

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> Semantically wrong code cannot be made correct by doing that.

That's not true. If it happens that a defined evaluation order
would do what the programmer wanted, then the code would indeed
become correct.

> it is like to define the result of A [-99999999999] as 0

No, it's not nearly as bad, because in the case of evaluation order,
we are specifying one of a set of legal results, whereas for indexing
there is no legal result.

> Wrong code should not go so far.

But there is (nearly) nothing to be gained by forcing the code to be
considered wrong.

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:pT_Sb.6670$bn1.3505@nwrdny02.gnilink.net...
> Randy Brukardt wrote:
> > Sorry, Hyman, but Ada has a very specific meaning for "unspecified
result",
> > and that's what people here (usually) mean. "Unspecified" means not only
is
> > *any* result allowed, but also that the implementer doesn't even need to
> > tell you what the result will be.
>
> That doesn't seem to be correct. Here's a quote from 1.1.3 of the ARM:
>      Certain aspects of the semantics are defined to be either
>      implementation defined or unspecified. In such cases, the
>      set of possible effects is specified, and the implementation
>      may choose any effect in the set. Implementations shall document
>      their behavior in implementation-defined situations, but
>      documentation is not required for unspecified situations.
>
> So I would have to say you're wrong. Unspecifed behavior allows the
> implementation to choose from a limited set of possible effects, not
> from an unlimited one, and the implementation doesn't have to tell
> you what it chooses.

I think you're misinterpreting the meaning of this paragraph. Only bounded
errors always give a set of possible results. There is an implied
requirement for sensible choices, but certainly the RM rarely if ever gives
a set of results for either I-D or unspecifed.

Try 13.9(11), for instance (Unchecked_Conversion). It says that the result
is I-D, but never says anything about the possible results (other than that
it may be abnormal!). I know of compilers that reject such conversions;
others do various masking operations; and still others raise exceptions.
That's pretty close to the entire set of possible results!

I note that the AARM notes say "Note that the ``set of possible effects''
can be ``all imaginable effects''; which seems to be the default case. So I
think that the only purpose of that phrase is to allow the RM to give a set
of possible results -- something it rarely if ever does.

                   Randy.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> So I think that the only purpose of that phrase is to allow the RM to give a set
> of possible results -- something it rarely if ever does.

When it speaks about order of evaluation, it says that the operands are
evaluated in "arbitrary order". That clearly results in a limited set of
possible results.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Mon, 02 Feb 2004 12:01:19 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
>> Semantically wrong code cannot be made correct by doing that.
>
>That's not true. If it happens that a defined evaluation order
>would do what the programmer wanted, then the code would indeed
>become correct.

I do not think so. + is commutative, if a programmer uses it so that
a+b /= b+a, he makes a semantical error. Later on, he may forget about
his mistake, a code viewer will be even not aware about it. So I treat
it as a *wrong* code. A wrong code may under some circumstances
function properly, false => true. You want to fix the circumstances, I
prefer to fix the code.

>> it is like to define the result of A [-99999999999] as 0
>
>No, it's not nearly as bad, because in the case of evaluation order,
>we are specifying one of a set of legal results, whereas for indexing
>there is no legal result.

The results are illegal, if different [*]. When a programmer writes:
x:=a+b, the postcondition of that is:

{ x=a+b & x=b+a }

so there is no legal way to make it dependent on the evaluation order.

>> Wrong code should not go so far.
>
>But there is (nearly) nothing to be gained by forcing the code to be
>considered wrong.

Yes, if that cannot be checked. As I always said, I wished to have
pure functions in Ada.

------
* Floating point numbers are intervals and equations become inclusions
and the postcondition will hold.

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
 > + is commutative

Mathematics went beyond dogmatic statements like that many years ago.
Notice you didn't say that * is commutative. Very disingenuous.

> You want to fix the circumstances, I prefer to fix the code.

Once the circumstances are fixed, the code is no more broken
than if the operands were evaluated in sequential statements.

> The results are illegal, if different [*].

Can you point to where the ARM says so? I believe you are wrong.

> When a programmer writes: x:=a+b, the postcondition of that is:
> { x=a+b & x=b+a }

If I replace + with *, you would find no one agreeing with you if the
operands were matrices, for example.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Tue, 03 Feb 2004 09:06:52 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Dmitry A. Kazakov wrote:
> > + is commutative
>
>Mathematics went beyond dogmatic statements like that many years ago.
>Notice you didn't say that * is commutative. Very disingenuous.

Well, on numbers with overflow + is as non-commutative as * for
matrices. Commutativity is not a property of the sign "+". And
compilers do not try to optimize user-defined types just because they
have "+" defined, I hope.

>> You want to fix the circumstances, I prefer to fix the code.
>
>Once the circumstances are fixed, the code is no more broken
>than if the operands were evaluated in sequential statements.

Nope, false => true, but this does not make false premise true.

>> The results are illegal, if different [*].
>
>Can you point to where the ARM says so? I believe you are wrong.

I didn't talk about ARM. However, it mentions mathematically correct
result. If a+b differs from b+a more than accuracy requirements allow,
it is no more mathematically correct.

>> When a programmer writes: x:=a+b, the postcondition of that is:
>> { x=a+b & x=b+a }
>
>If I replace + with *, you would find no one agreeing with you if the
>operands were matrices, for example.

For matrices * is not commutative. We are discussing commutative
operators.

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Dmitry A. Kazakov wrote:
> For matrices * is not commutative. We are discussing commutative
> operators.

Ada allows + to be a user-written function. When this is done,
the function receives the operands in the order written in the
code. The operation is commutative only if this function wants
it to be. And "we" are not discussing commutative operators.
You are, in raising all of these crypto-mathematical objections
to fixing an order of evaluation. I have yet to find any of these
objections at all compelling - your theories seem to have nothing
to do with the actual process of writing code in Ada, either as
it now stands or as I think it should.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 03 Feb 2004 11:11:23 -0500, Hyman Rosen wrote:

> I have yet to find any of these
> objections at all compelling 

The person who raised the argument and persists in arguing one side
doesn't find the counter-arguments compelling. Shocking.

> your theories seem to have nothing
> to do with the actual process of writing code in Ada, either as
> it now stands or as I think it should.

It violates the expectations of a maintaining programmer.

To run into this problem, you'd usually be writing clumsy, hard to follow
code that needs to be fixed, not patched at the language level. 

Your solution papers over the problem instead exposing it and getting it
fixed in the code, like it should be and which is done with the array and
pointer examples you keep bringing up.

You have to test the production version of your software already. You
never know what different switches will do to your code whether so
authorized by the standard or not.

All those arguments have to do with the writing of code in Ada.

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> The person who raised the argument and persists in arguing one side
> doesn't find the counter-arguments compelling. Shocking.

There are plenty of times where I am convinced that a position I hold
has compelling counter-arguments. This is not one of them. I have yet
to hear why a deliberate ambiguity is better than a definite order.

> It violates the expectations of a maintaining programmer.

So your point is that the language should increase the possibility of
error instead? This just makes no sense. I really get the sense that
people are clinging desperately to "we've always done it this way".

> To run into this problem, you'd usually be writing clumsy, hard to follow
> code that needs to be fixed, not patched at the language level. 

To belabor the point once more,
     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
is not clumsy or hard to follow, merely wrong in the status quo.

> Your solution papers over the problem

My solution makes it no longer be a problem.

> the array and pointer examples you keep bringing up.

I haven't brought them up in the context of Ada, only C/C++.

> You have to test the production version of your software already. You
> never know what different switches will do to your code whether so
> authorized by the standard or not.

True. But that doesn't mean that errors couldn't slip in anyway.
Errors that could be prevented at no cost to the programmer.

> All those arguments have to do with the writing of code in Ada.

I don't find that compelling :-)

Re: In-Out Parameters for functions

[David Starner]

On Tue, 03 Feb 2004 18:38:26 -0500, Hyman Rosen wrote:

> David Starner wrote:
>> The person who raised the argument and persists in arguing one side
>> doesn't find the counter-arguments compelling. Shocking.
> 
> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.

You're still far from an impartial judge.

>> It violates the expectations of a maintaining programmer.
> 
> So your point is that the language should increase the possibility of
> error instead? This just makes no sense. 

It shouldn't make things right just because it can. It should make
things right because they are logically right.

>> To run into this problem, you'd usually be writing clumsy, hard to follow
>> code that needs to be fixed, not patched at the language level. 
> 
> To belabor the point once more,
>      p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> is not clumsy or hard to follow, merely wrong in the status quo.

I have some pieces of code in response:

for I in 0.0 .. 1.0 step 0.25
is not clumsy or hard to follow, merely wrong in the status quo. But
making it right would bring in a lot of other stuff that won't work right.

x : 0..1 := 0;
function f : integer is begin x := 1 - x; return x; end f;
r : integer := f - f;

This isn't the clearest bit of code in the first place; on first glance, I
want to say that r is 0. I have to read the implementation details of f to
figure out what's going on. If it were

x: 0..1 = 0;
function f (z : integer) : integer is begin 
	x := x - z; 
	return x - z; 
end f;

r: integer = f (x);

then we would have stepped into another of Ada's constructive ambiguities,
the fact that x may have been passed by copy or by reference. In a
real-life program, the same code that produces the first will quite
possibly run into the second problem. And if you don't, that doesn't mean
that the maintainer, who doesn't understand the program as well, won't.

>> Your solution papers over the problem
> 
> My solution makes it no longer be a problem.

In any real program, diddling with a bunch of global variables is likely
to be hard to maintain and hard to reason about. Any thing that assumes
that the interpretation order of a line is left to right is going to be
adding sequence points where most languages don't have them and most code
doesn't have them and is going to be surprising to a maintainer, and
probably missed without comments.
 
>> the array and pointer examples you keep bringing up.
> 
> I haven't brought them up in the context of Ada, only C/C++.

You've mentioned how they differ between Ada and C. But it's different to
make something an loud error and make it legal.

> True. But that doesn't mean that errors couldn't slip in anyway. Errors
> that could be prevented at no cost to the programmer.

And this could cause errors, by making things legal that are hard to
reason about and actually program with. And there's a cost to the
programmer, because it's a loss of an optimization opportunity and hence a
slower program at the end.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> > + is commutative
>
> Mathematics went beyond dogmatic statements like that many years ago.
Very interesting information. May I ask you for a couple of references? I mean
authoritative mathematical books where plus sign (+, without any modifications)
denotes some non-commutative operation.

And also, if the value of "pi" or "e" constant is somehow changed recently
(or if they are no longer constants) - in modern mathematics - then please
tell us that.



Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Ludovic Brenta]

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

> And also, if the value of "pi" or "e" constant is somehow changed recently
> (or if they are no longer constants) - in modern mathematics - then please
> tell us that.

Don't you know? 2+2=5, but only for large values of 2.

:)

-- 
Ludovic Brenta.

Re: In-Out Parameters for functions

[Alexandre E. Kopilovitch]

Hyman Rosen wrote:

> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.
Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
earlier - I thought that you wanted to understand. So, here is a compelling
argument: consider a deliberate ambiguity in choosing of the next leader of
a country in democratic societies, and compare it with quite definite order 
of that in absolute monarchies and totalitarian (Communists and others) regimes.
Which mode you like better?

But if you want purely scientific/technical and at the same time compelling
and condensed argument then I must disappoint you - you have very little
chance for getting it for free, simply asking for it - in this case. For free
you can get a hint only, and you already refused it. Well, you have an option: turn to 
ARA or to some Ada-related vendor and ask them whether they can and will
supply you a compelling argument on this matter for $$$. Perhaps they will agree.




Alexander Kopilovitch                      aek@vib.usr.pu.ru
Saint-Petersburg
Russia

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

> I have yet
>to hear why a deliberate ambiguity is better than a definite order.

Because it is better to remove the ambiguity instead of making it look
like something else when in fact it isn't.


Vinzent.

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 04 Feb 2004 04:26:34 +0100, Ludovic Brenta
<ludovic.brenta@insalien.org> wrote:

>"Alexandre E. Kopilovitch" <aek@VB1162.spb.edu> writes:
>
>> And also, if the value of "pi" or "e" constant is somehow changed recently
>> (or if they are no longer constants) - in modern mathematics - then please
>> tell us that.
>
>Don't you know? 2+2=5, but only for large values of 2.
>
>:)

if 2 + 2 = 5 then
   5 := 4;
end if;

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

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:

> There are plenty of times where I am convinced that a position I hold
> has compelling counter-arguments. This is not one of them. I have yet
> to hear why a deliberate ambiguity is better than a definite order.

I am no expert in these matters, but I thought that at some
time in the [distant] past the argument was made that the
ambiguity allows optimization: in particular optimization in
systems employing highly parallel computing architectures.

In such systems, different parts of an expression could be
'farmed out' and computed in parallel because there was no
assumption of any sequential order.

This argument should also have merit in cases where
processors have multiple execution units and support for
out-of-order execution.  Just how far must a compiler go in
preserving the sequential order written in the source code?

I would agree with you that in most run-of-the-mill software
cases the lack of definite execution order does create a
pitfall for the unwary.  But, it also creates an opportunity
for 'smart compilers' to optimize.  In the end, surely, the
language must strike a balance in judging the true intent of
an author (when they are writing vanilla programs).  Is the
serialization of an expression a specific requirement or an
unwanted by-product of the format of the source code!

On balance [however much I might find it a pain in my line
of programming], I think that the language has chosen the
most pragmatic approach.  Those of us who are really
concerned about the matter will add it to our list of
concerns [and then probably turn to SPARK to save us from
ourselves :-) ]

--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
>>     p : Point := (x => ReadCoord, y => ReadCoord, z => ReadCoord);
> 
> I have some pieces of code in response:
> for I in 0.0 .. 1.0 step 0.25

Is this currently legal in Ada? Remember that my example is.

> the fact that x may have been passed by copy or by reference.

OK, I accept that there are more ambiguity issues than I have
been cnsidering. I suppose you object to getting rid of those too?

> In any real program, diddling with a bunch of global variables is likely
> to be hard to maintain and hard to reason about.

But using functions that read input is not hard to reason about.
     BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);
Someone might reasonably think that the above line of code should fill
the array with sensor readings in order. You can tell him that it won't
work that way, but you can hardly say that he had no right to expect that
it would.

> sequence points where most languages don't have them

Java does, and many people are now exposed to that.
The Java language refernce manual also recommends not writing code
which exploits this, though, so that's one for your side. I think
it's just atavistic dread from the reptillian hindbrain.

 > it's a loss of an optimization opportunity

But it's not, except for programs which are now exhibiting unspecified
behavior. If an expression has only one value regardless of execution
order, then the compiler will be free to evaluate it in any order.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Because it is better to remove the ambiguity instead of making it look
> like something else when in fact it isn't.

But Ada doesn't necessarily warn you that such an ambiguity exists,
so it might wind up not getting removed.

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
 > But, it also creates an opportunity for 'smart compilers' to optimize.

Notice that if an expression has only one possible value regardless of
evaluation order then the compiler can evaluate it in any order it wants,
and with the current evaluation rules, it is unwise to write expressions
that have more than one possible value based on evaluation order. So no
correct existing programs necessarily need to be pessimized by fixing
evaluation order.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Because it is better to remove the ambiguity instead of making it look
>> like something else when in fact it isn't.
>
>But Ada doesn't necessarily warn you that such an ambiguity exists,
>so it might wind up not getting removed.

Well, IMO it doesn't get removed just by fixing the evaluation order,
either. It still is wrong code and as such it is the *code* that has
to be fixed.


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>it is unwise to write expressions that have more than one possible
>value based on evaluation order.

It is not only unwise, it is plain stupid.

>So no correct existing programs necessarily need to be pessimized by
>fixing evaluation order.

Precisely. You don't need to fix the evaluation order. It wouldn't
help anyway because the code remains to be stupid.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Well, IMO it doesn't get removed just by fixing the evaluation order,
> either. It still is wrong code and as such it is the *code* that has
> to be fixed.

What is it about definite order of evaluation that you and so
many others find intrinsically evil?

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> It is not only unwise, it is plain stupid.

Under current rules.

> Precisely. You don't need to fix the evaluation order. It wouldn't
> help anyway because the code remains to be stupid.

It would help by making the "stupid" code work the same way
everywhere, cutting down an opportunity for error. And then
it would lead to non-stupid uses, such as the initialization
code I've been posting.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Well, IMO it doesn't get removed just by fixing the evaluation order,
>> either. It still is wrong code and as such it is the *code* that has
>> to be fixed.
>
>What is it about definite order of evaluation that you and so
>many others find intrinsically evil?

Because it forces the programmer to think about optimization instead
of thinking about readability.


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>It would help by making the "stupid" code work the same way
>everywhere, cutting down an opportunity for error. And then
>it would lead to non-stupid uses, such as the initialization
>code I've been posting.

Maybe. But it will also lead to more stupid code because we now know
about the evaluation order and thus can (or even: must) do
optimizations ourselves. That sort of optimizations that we would
normally leave to the compiler.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Because it forces the programmer to think about optimization instead
> of thinking about readability.

How does it do that? Is the programmer forced to think about optimization
instead of readability when he writes a sequence of statements?

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Maybe. But it will also lead to more stupid code because we now know
> about the evaluation order and thus can (or even: must) do
> optimizations ourselves. That sort of optimizations that we would
> normally leave to the compiler.

Do you have an example? What sort of optimization is implied by
order of evaluation that would lead a programmer to choose one
way over another?

Re: In-Out Parameters for functions

[David Starner]

On Wed, 04 Feb 2004 10:52:14 -0500, Hyman Rosen wrote:

> What is it about definite order of evaluation that you and so
> many others find intrinsically evil?

Have you ever studied functional programming? I think part of the
objection is the concept that pure functional programming is the ideal and
that we differ from that for efficiency and a closer mapping to the
hardware.

Also, half the examples have been horrible code that should never be
written. So much of the code enabled by this feature can't be fixed
to use it without a program-wide analysis of the problems, wherein it
would be just as easy to fix the code not to depend on evaluation order.

> OK, I accept that there are more ambiguity issues than I have
> been cnsidering. I suppose you object to getting rid of those too?

That would require major surgery to the language that would leave it
backwardly-incompatible or require the compiler to do stupid slow things.
If you want Java, you know where to find it.

In any case, you have a huge group of ambiguity issues around threads.
It's inherent in the system. If you're worried about your compiler
changing evaluation order at compile time, wait until your program starts
behaving erratically at run time because you made the same mistakes.

> But using functions that read input is not hard to reason about.
>      BunchOfReadings : array(1..100) of Integer := (others => ReadSensor);

Which it is easy to warn about and simple to fix.

> But it's not, except for programs which are now exhibiting unspecified
> behavior. If an expression has only one value regardless of execution
> order, then the compiler will be free to evaluate it in any order.

If the compiler can prove that, which is easier said then done. At best,
it will slow down compilers at compile-time, proving what they could
assume before, and slow down programs at run-time when they couldn't prove
it.

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:
> 
> Stuart Palin wrote:
>  > But, it also creates an opportunity for 'smart compilers' to optimize.
> 
> Notice that if an expression has only one possible value regardless of
> evaluation order then the compiler can evaluate it in any order it wants,
> and with the current evaluation rules, it is unwise to write expressions
> that have more than one possible value based on evaluation order. So no
> correct existing programs necessarily need to be pessimized by fixing
> evaluation order.

But the premise in many of your other postings in this
thread seems to be concerned with resolving the case where
the expression [currently] has an 'ambiguous' value.

As has already been pointed out in this thread, an Ada
compiler can not determine - simply from its specification -
whether a function will have a side-effect or not.  (SPARK
resolves the issue by extending specifications with
annotations; but then it is striking a different balance
between  flexibility in the design and verifiability of
behaviour).

I agree with you that it is unwise to write expressions that
[unintentionally] have more than one possible value; but I
think the point I made still stands.  Ada seems to have (as
a matter of pragmatism) chosen not to prohibit certain
aspects of ambiguity because the potential benefits [in a
wide range of cases] out-weigh the pitfalls.

[Again, re-affirming my lack of expertise in these matters
of the Ada language, the 'pragmatic view' seems to be that:
a) people would mostly write functions without side-effects,
b) if they are writing functions with side-effects they
would/should be especially careful how they use them anyhow,
and c) Good performance in embedded real-time systems (on a
variety of targets) is desirable [essential if you consider
Ada to be targeted at the real-time embedded application
market]: consequently, in general the order of evaluation is
not fixed; allowing compilers to find an optimal
implementation order - including concurrent computation.

This may seem even more reasonable if one acknowledges there
are other cases where ambiguous behaviour can arise - for
instance data aliasing through parameter passing (another
thing prevented by SPARK) - so the die is cast!]

If your proposal to define the execution order were to be
adopted, how might a programmer write the Ada code to
express their intent that they don't care what order the
expression is executed in (provided it respected the
precedence rules) - they just want the most efficient
implementation?

How much do you think this [manual optimization] would add
to/detract from the clarity of the code?

How do you think someone who is writing applications for a
target that offers high levels of parallel computation would
feel about it?

--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
> But the premise in many of your other postings in this
> thread seems to be concerned with resolving the case where
> the expression [currently] has an 'ambiguous' value.

Yes.

> As has already been pointed out in this thread, an Ada
> compiler can not determine - simply from its specification -
> whether a function will have a side-effect or not.

Yes.

> Ada seems to have (as
> a matter of pragmatism) chosen not to prohibit certain
> aspects of ambiguity because the potential benefits [in a
> wide range of cases] out-weigh the pitfalls.

Those benefits being?

> allowing compilers to find an optimal implementation order

But you are now talking about finding an optimal implementation
order for an expression involving more than one function call
where the compiler has no access to the body of the functions.
Do you really think that allowing the compiler to pick the order
of the calls will significantly affect the efficiency?

> - including concurrent computation.

I don't see how this can possibly be allowed, unless the compiler
can see the bodies to inline them. The standard allows operands
and arguments to be evaluated in arbitrary order, but concurrent
execution would completely break any functions that accessed common
data structures.

> This may seem even more reasonable if one acknowledges there
> are other cases where ambiguous behaviour can arise - for
> instance data aliasing through parameter passing

Eliminating sources of ambiguity is a good thing even if not all
of them can be removed.

> If your proposal to define the execution order were to be
> adopted, how might a programmer write the Ada code to
> express their intent that they don't care what order the
> expression is executed in

They could not, just as they cannot specify this for sequences
of statements. If you write
     x := a + b;
     y := c + d;
you may not care which statement is executed first, but you have no
way of telling this to the compiler. Either the compiler can figure
this out for itself, or it can't.

> How much do you think this [manual optimization] would add
> to/detract from the clarity of the code?

I think this is non-existent now, and will continue to be so.

> How do you think someone who is writing applications for a
> target that offers high levels of parallel computation would
> feel about it?

They would feel that order of evaluation is completely orthogonal
to their concerns.

Re: In-Out Parameters for functions

[Hyman Rosen]

Alexandre E. Kopilovitch wrote:
> Ah, you just wanted a compelling argument! Sorry, I didn't get you properly
> earlier - I thought that you wanted to understand. So, here is a compelling
> argument: consider a deliberate ambiguity in choosing of the next leader of
> a country in democratic societies, and compare it with quite definite order 
> of that in absolute monarchies and totalitarian (Communists and others) regimes.
> Which mode you like better?
> 
> But if you want purely scientific/technical and at the same time compelling
> and condensed argument then I must disappoint you - you have very little
> chance for getting it for free, simply asking for it - in this case. For free
> you can get a hint only, and you already refused it. Well, you have an option: turn to 
> ARA or to some Ada-related vendor and ask them whether they can and will
> supply you a compelling argument on this matter for $$$. Perhaps they will agree.

"Ladies and gentlemen of the supposed jury, I have one final thing I want you
to consider: this is Chewbacca. Chewbacca is a Wookiee from the planet Kashyyyk,
but Chewbacca lives on the planet Endor. Now, think about that. That does not
make sense!

"Why would a Wookiee -- an eight foot tall Wookiee -- want to live on Endor with
a bunch of two foot tall Ewoks? That does not make sense!

"But more importantly, you have to ask yourself: what does that have to do with
this case? Nothing. Ladies and gentlemen, it has nothing to do with this case!
It does not make sense!

"Look at me, I'm a lawyer defending a major record company, and I'm talkin' about
Chewbacca. Does that make sense? Ladies and gentlemen, I am not making any sense.
None of this makes sense.

"And so you have to remember, when you're in that jury room deliberating and
conjugating the Emancipation Proclamation... does it make sense? No! Ladies and
gentlemen of this supposed jury, it does not make sense.

"If Chewbacca lives on Endor, you must acquit! The defense rests."

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?

Of course it will.  Consider for one example a Pure subprogram, say a 
call to Sin or Log from a math package inside a loop.  The pragma Pure 
rules allow the compiler to hoist the call outside the loop, if the 
parameter(s) are unchanged in successive calls.

YOU may think that is a contrived example, but it is not.  That sort of 
thing happens all the time in embedded flight dynamics systems where a 
set of expressions is iterated a couple of times for convergence.  And 
even if the expressions are not iterated, they often include common 
subexpressions that can be pulled out of line by the compiler.  Any call 
to a Pure function can be treated as a common subexpression, even if the 
subprogram itself is not inlined.

This is one of the nice features of Ada for safety-critical systems. 
The formulas for things like flight dynamics can be almost copied 
verbatum from the specification, and the compiler (and Verifier!) can do 
the grody work of finding an efficient implementation and showing that 
it is equivalent.

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> But you are now talking about finding an optimal implementation
>> order for an expression involving more than one function call
>> where the compiler has no access to the body of the functions.
>> Do you really think that allowing the compiler to pick the order
>> of the calls will significantly affect the efficiency?
> 
> Of course it will.  Consider for one example a Pure subprogram, say a 
> call to Sin or Log from a math package inside a loop.  The pragma Pure 
> rules allow the compiler to hoist the call outside the loop, if the 
> parameter(s) are unchanged in successive calls.

Sigh. When I said "access to the body" I meant that the compiler has
no more information about what the function does than its declaration.
Obviously if a function is declared Pure then its return value is not
affected by order of execution, and the compiler can hoist away.

Think about it - if you write
     s := Sin(x) + Cos(y)
Ada requires that both arguments are evaluated, but doesn't specify the
order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
each time in a loop, but can hoist the calculations out, as you say. Why
would specifying the order change this?

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Think about it - if you write
>     s := Sin(x) + Cos(y)
> Ada requires that both arguments are evaluated, but doesn't specify the
> order. Yet, with a pragma Pure in place, Ada need not evaluate the operands
> each time in a loop, but can hoist the calculations out, as you say. Why
> would specifying the order change this?

That may be why you keep butting your head against a brick wall.  If Ada 
said that in an equation like: s := Sin(1-x) + Cos(y); that the terms 
had to be evaluated left to right, that would say you couldn't evaluate 
Cos(y) before Sin(1-x) whether or not they were declared Pure.

Ada does allow compilers to combine calls to Pure functions, and if that 
is not okay, don't declare them Pure.  But that doesn't say that Pure 
functions can't have side effects.  It just changes what a compiler is 
allowed to do with Pure functions.  In fact, right now on the ARG list 
we are discussing a fix to 10.2.1 Elaboration Control which defines 
pragma Pure and pragma Preelaborate.  There are some new features in Ada 
0Y that require some wording changes, and we want them to be as 
restrictive as necessary, but no stricter.  In that discussion we have 
discussed exactly this issue.  (A Pure subprogram call can be 
eliminated, and if the subprogam has side-effects, well the programmer 
was warned.  No different from some other effects of optimizing compilers.

But note that what users have been warned about is that marking a unit 
as Pure may allow the optimizer to eliminate some calls.  The compilers 
are not allowed to call the function somewhere that it wouldn't be 
called otherwise.  The compiler must insure that a Pure function that 
would never be called in the canonical order is never called in the 
order the compiler selects.  And if two Pure functions have side 
effects, and both are called, the side effects must happen in the right 
order.

So the new rule that you are proposing would severly limit some very 
useful optimizations, unless you had exceptions for Pure functions, and 
predefined operators, and static expressions, and... Well you get the 
picture.  Soon you have more exceptions than case that are constrained 
by the rule, and all to insure that functions with side-effects are 
called in a single canonical order.

We prefer to have one easily understood set of rules.  Unfortunately in 
some useful cases these rules work out to "if you really want to be 
sure, install a block with an exception handler."  But this is based on 
twenty years of experience.  Users at all levels don't want strict 
execution orders in most cases, but they all seem to want very good 
optimization.

Also note incidently that what some users really do care about, and 
which has raised entirely too much discussion for something that will 
never be changed, is short-circut expression evaluation.  I don't know 
how many requests I have seen in various forms for redefining 'or' to 
mean 'or else' and 'and' to mean 'and then'.  (The proposals for the 
current meanings of 'and' and 'or' have lots of different syntax 
suggestions associated with them.)  But the real unalterable answer is 
NO! (Or maybe something more forceful.)  There is too much existing code 
that depends on the current rules and the cost of revising that code is 
totally out of proportion to the potential savings--which I don't even 
think exist.  The compiler can use short circut forms if the expression 
after 'and' or 'if' is marked Pure or a static expression, or only 
involves predefined expressions, etc.  (See the similar list above, 
which is what brought it to mind. ;-)

So the only cases where the proposed rule change would make a difference 
are exactly those cases that would have to be revised in existing code. 
And when you check on why the request was made, it often resulted from 
an error message at compile time.  The message can always be eliminated 
by changing the 'and' to 'and then' or the 'or' to 'or else'.  But in 
practice the programmer really has to think to be sure that is the right 
change.

It is the required thinking that seems to generate the revision 
requests. If 'and then' and 'or else' were the defaults then they 
wouldn't need to think during compilation, and they could wait for an 
exception at run-time. ;-)

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

Re: In-Out Parameters for functions

[Stuart Palin]

Hyman Rosen wrote:

> > Ada seems to have (as
> > a matter of pragmatism) chosen not to prohibit certain
> > aspects of ambiguity because the potential benefits [in a
> > wide range of cases] out-weigh the pitfalls.
> 
> Those benefits being?
> 
> > allowing compilers to find an optimal implementation order

... allowing compilers to find an optimal implementation
order!???

> But you are now talking about finding an optimal implementation
> order for an expression involving more than one function call
> where the compiler has no access to the body of the functions.
> Do you really think that allowing the compiler to pick the order
> of the calls will significantly affect the efficiency?
> 
> > - including concurrent computation.

Yes - as Robert Eachus has illustrated much better than I
could.

> Eliminating sources of ambiguity is a good thing even if not all
> of them can be removed.

Agreed, but to emphasize the point made by Robert Eachus -
if the rules you introduce are too complex the cure is worse
than the disease.  There is some merit in having a set of
rules that are perhaps imperfect, but are simpler to
understand: at least you are sure of where you stand.

> > If your proposal to define the execution order were to be
> > adopted, how might a programmer write the Ada code to
> > express their intent that they don't care what order the
> > expression is executed in
> 
> They could not, just as they cannot specify this for sequences
> of statements. If you write
>      x := a + b;
>      y := c + d;
> you may not care which statement is executed first, but you have no
> way of telling this to the compiler. Either the compiler can figure
> this out for itself, or it can't.

or you could possibly identify that x and y are part of a
common object and so might be processed jointly:

   type doublet is record
     x : ... ;
     y : ... ;
   end record;
   ...
   XY : doublet;
   ...

   XY := doublet'(x => a+b, y => c+d);

If they are truly unconnected objects then perhaps they
should be processed in separate tasks.

However, I think that in practice the language has taken a
pragmatic view of where to draw the line in balancing
'ambiguity' of order with optimization: within a single
expression the order of evaluation may be ambiguous, between
separate statements it may not.
--
Stuart Palin

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> That may be why you keep butting your head against a brick wall.  If Ada 
> said that in an equation like: s := Sin(1-x) + Cos(y); that the terms 
> had to be evaluated left to right, that would say you couldn't evaluate 
> Cos(y) before Sin(1-x) whether or not they were declared Pure.
> 
> Ada does allow compilers to combine calls to Pure functions, and if that 
> is not okay, don't declare them Pure.  But that doesn't say that Pure 
> functions can't have side effects.  It just changes what a compiler is 
> allowed to do with Pure functions.

I am not butting my head against a brick wall, I am butting into brick heads.
(Who was it who defined teaching as the art of pounding abstract facts into
concrete heads? :-)

Right now, the ARM says that the operands in an expression are evaluated in
arbitrary order, and I would propose that it say that operands are evaluated
left-to-right. Neither of those statements gives any permission to not call
a subprogram present in an expression.

The section that specifies pragma Pure says that under certain circumstances,
a call to a pure function may be omitted and replaced with the results of a
previous call. That would remain as true in the left-to-right version as in
the arbitrary order version. The concepts are entirely orthogonal.

Re: In-Out Parameters for functions

[Hyman Rosen]

Stuart Palin wrote:
> ... allowing compilers to find an optimal implementation order!???

But as you go on to quote me, the cases where the compiler would not
be permitted to do this are relatively rare, and involve the presence
of multiple function calls within an expression. In such a case, how
much optimization will operand reordering buy?

>>>- including concurrent computation.

Where does Ada permit the concurrent execution of multiple function
calls of an expression?

> if the rules you introduce are too complex the cure is worse
> than the disease.

Fortunately, the rules I introduce are not.

> There is some merit in having a set of rules that are perhaps
 > imperfect, but are simpler to understand: at least you are sure
 > of where you stand.

Yes, that's what my rules would accomplish. There are many people
who are astonished to realize that in
     a := f(a(0)) + g(b(1));
the only constraints are that a is called before f and b before g,
but nothing else is required, so that six orders are possible:
     abfg abgf afbg bafg bagf bgaf

>    XY := doublet'(x => a+b, y => c+d);
> 
> If they are truly unconnected objects then perhaps they
> should be processed in separate tasks.

I will leave it to the people who describe Ada code as readeable to
tell me whether turning a sequence of assignments into an aggregate
or a pair of tasks is a good idea.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 01:55:41 +0000, Hyman Rosen wrote:
> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
>      a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
>      abfg abgf afbg bafg bagf bgaf

And there are many people who would be astonished if it matters
and feel compelled to go find the author and beat them over the
head with the ARM.

In any case, there are a lot of things many people would be
astonished to realize. Many people were astonished to realize
that C ints weren't 16 bits long; that didn't mean that the
standard should have changed the definition. Many people
are also astonished to find out that the size of an integer
isn't necessarily the same size as a pointer. 

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:

> Where does Ada permit the concurrent execution of multiple function
> calls of an expression?

Nowhere (I can remember) - except that "arbitrary order" in my eyes
includes "at the same time".

> Yes, that's what my rules would accomplish. There are many people
> who are astonished to realize that in
>      a := f(a(0)) + g(b(1));
> the only constraints are that a is called before f and b before g,
> but nothing else is required, so that six orders are possible:
>      abfg abgf afbg bafg bagf bgaf

Since Ada specifically is targeted to concurrent processing I find
that astonishment a bit strange.  But maybe those people you're
thinking of aren't used to concurrent processing?

> >    XY := doublet'(x => a+b, y => c+d);
> > If they are truly unconnected objects then perhaps they
> > should be processed in separate tasks.
> 
> I will leave it to the people who describe Ada code as readeable to
> tell me whether turning a sequence of assignments into an aggregate
> or a pair of tasks is a good idea.

If the objects are _logically_ unconnected, the above notation implies
a connection between the objects that only exists for the sake of this
specific implementation.  That may confuse later maintainers of the
code.

Jacob
-- 
"Banning open source would have immediate, broad, and
 strongly negative impacts on the ability of many sensitive
 and security-focused DOD groups to protect themselves
 against cyberattacks"                        -- Mitre Corp.

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

From: "Jacob Sparre Andersen" <sparre@nbi.dk>
> Hyman Rosen wrote:
>
> > Where does Ada permit the concurrent execution of multiple function
> > calls of an expression?
>
> Nowhere (I can remember) - except that "arbitrary order" in my eyes
> includes "at the same time".
Definitely not. 1.1.4 (18):
   Whenever the run-time semantics defines certain actions to happen in an arbitrary order, this means that
   the implementation shall arrange for these actions to occur in a way that is equivalent to some sequential order,
   following the rules that result from that sequential order.

Otherwise it would mean that all functions should protect themselves against concurrent evaluation, even if there are not tasks in
the program!
Of course, if a compiler determines that a function has no side effect, it can do concurrent evaluation under the "as if" rule. Note
that the rule really says that "it shall be equivalent to some sequential order", not that it is evaluated sequentially.
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> And there are many people who would be astonished if it matters
> and feel compelled to go find the author and beat them over the
> head with the ARM.

As I have said over and over again, the problematic case is when
it matters, and no one notices, and the compiler happens to do
what you want. Then a change in environment could result in the
order changing, and all of a sudden, code mysteriously breaks.

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> As I have said over and over again, the problematic case is when
> it matters, and no one notices, and the compiler happens to do
> what you want. Then a change in environment could result in the
> order changing, and all of a sudden, code mysteriously breaks.

And the life and death case is when it matters and the compiler does
what you want, and then maintainers change something, and after they
discover there were uncommented, incredibly subtle order issues, they
go out to kill the original smart-ass programmer. 

Re: In-Out Parameters for functions

[Stephen Leake]

David Starner <dvdeug@email.ro> writes:

> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
> > As I have said over and over again, the problematic case is when
> > it matters, and no one notices, and the compiler happens to do
> > what you want. Then a change in environment could result in the
> > order changing, and all of a sudden, code mysteriously breaks.
> 
> And the life and death case is when it matters and the compiler does
> what you want, and then maintainers change something, and after they
> discover there were uncommented, incredibly subtle order issues, they
> go out to kill the original smart-ass programmer. 

I think Hyman has two valid points:

1) if the language specified left-to-right order, there would never be
   a need to "kill the original smart-ass programmer"

2) Does anyone have a real example of a compiler taking advantage of
   the evaluation order freedom to speed up a program?

Ada is supposed to be about clear, unsurprising code. Subtle order
issues are just that - "subtle". If the language _could_ make them a
non-issue, at very little cost, I think it _should_.

I have not heard anyone respond to 2), which is supposedly the reason
the freedom is there. If no compiler actually takes advantage of it,
it's not worth having.

I don't think there's much chance Ada will change in this area; it
would cost more to change the documentation than it is worth.

But we can at least be honest about it!

-- 
-- Stephe

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On 24 Feb 2004 19:44:12 -0500, Stephen Leake <stephen_leake@acm.org>
wrote:

>David Starner <dvdeug@email.ro> writes:
>
>> On Tue, 24 Feb 2004 09:51:44 -0500, Hyman Rosen wrote:
>> > As I have said over and over again, the problematic case is when
>> > it matters, and no one notices, and the compiler happens to do
>> > what you want. Then a change in environment could result in the
>> > order changing, and all of a sudden, code mysteriously breaks.
>> 
>> And the life and death case is when it matters and the compiler does
>> what you want, and then maintainers change something, and after they
>> discover there were uncommented, incredibly subtle order issues, they
>> go out to kill the original smart-ass programmer. 
>
>I think Hyman has two valid points:
>
>1) if the language specified left-to-right order, there would never be
>   a need to "kill the original smart-ass programmer"

But also, if the language disallowed side-effects when there could be
more than one order. I prefer the second, provided that the term
"side-effect" should be formally defined by the language and visible
from the specifications.

>2) Does anyone have a real example of a compiler taking advantage of
>   the evaluation order freedom to speed up a program?

The question is what gets lost if an evaluation order is fixed. I gave
an example earlier:

for I in A'Range loop
   Sum := Sum + A (I) + B (B'First + I - A'First);
   ...

Here with left-to-right order the compiler cannot optimize neither the
array index of B, nor can it increment Sum by adding A()+B(). Well,
these optimizations could be made possible if the compiler might prove
that the result does not depend on the order. That could be quite
difficult to formally define, especially regarding numeric exceptions
and floating-point accuracy stuff. Even more difficult it would be
check.

But finally, if all that could be achived, then the compiler will be
capable to simply detect that different orders give different results,
and threat it as an error. Much better than fixing an arbitrary order!

So the bottom line, IMO, 1 makes no sense.

>Ada is supposed to be about clear, unsurprising code. Subtle order
>issues are just that - "subtle". If the language _could_ make them a
>non-issue, at very little cost, I think it _should_.

Right, the present situation is not good. But IMO the solution lies in
introducing formally pure functions and imposing limitations on use of
impure functions (and procedures with results) in expressions.

>I have not heard anyone respond to 2), which is supposedly the reason
>the freedom is there. If no compiler actually takes advantage of it,
>it's not worth having.
>
>I don't think there's much chance Ada will change in this area; it
>would cost more to change the documentation than it is worth.
>
>But we can at least be honest about it!

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

Re: In-Out Parameters for functions

[David Starner]

On Tue, 24 Feb 2004 19:44:12 -0500, Stephen Leake wrote:
> 1) if the language specified left-to-right order, there would never be
>    a need to "kill the original smart-ass programmer"

If it got changed in maintenance, and introduced a bug because no one
saw the hidden dependency, then there would be. 
 
> Ada is supposed to be about clear, unsurprising code. Subtle order
> issues are just that - "subtle". If the language _could_ make them a
> non-issue, at very little cost, I think it _should_.

But it doesn't change the meaning of much clear, unsurprising code. Most
of the examples depend on hidden state. The rest depend on I/O. Neither
occur much in clear, unsurprising code.

(Okay, so I/O is necessary in programs. But the examples using I/O
can be rewritten not to use this, and are usually pretty obvious.)
 
> I don't think there's much chance Ada will change in this area; it
> would cost more to change the documentation than it is worth.
> 
> But we can at least be honest about it!

I think part of it is language philosophy. Ada is not C, but it's not
Java, either. Ada's goal is not to make every program run exactly the same
everywhere. Perhaps the supposed efficiency goals aren't achieved by this
choice, but reversing the choice, and helping some marginal code become
legal, isn't a huge win in the terms of Ada's choices. 

Re: In-Out Parameters for functions

[Marin David Condic]

That is an issue I think we Ada fans often get caught up in. "Well, in 
*theory* an Ada compiler could do blah blah blah...." But if, in 
*practice*, none of them do and none of them have any plans to do so, 
then effectively "The Language" doesn't do it. A good example is when 
people post here asking "Does Ada have garbage collection?" We tell them 
the standard allows it, but nobody does it. Do they care that the 
standard allows it if they can't get a compiler that does it? The same 
goes for other issues like efficiency. A feature might theoretically be 
implementable in an efficient manner, but if nobody does it well in 
practice, you get the accusation "Ada is slow..." and its hard to argue 
against.

There is a real distinction between what the standard says and what 
might exist by way of implementations, but for most practical purposes, 
average developers don't make that distinction. Hence, there is a de 
facto "standard" which cannot be ignored.

MDC


Stephen Leake wrote:
> 
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

> 
> I have not heard anyone respond to 2), which is supposedly the reason
> the freedom is there. If no compiler actually takes advantage of it,
> it's not worth having.
> 

-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Re: In-Out Parameters for functions

[Hyman Rosen]

David Starner wrote:
> I think part of it is language philosophy.

What philosophy requires the retention of a feature
that offers no benefits and can be removed without
affecting legal programs?

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>David Starner wrote:
>> I think part of it is language philosophy.
>
>What philosophy requires the retention of a feature
>that offers no benefits and can be removed without
>affecting legal programs?

The philosophy that the semantics of a program should be the same, no
matter if you choose to write "f := a + b;" or "f = b + a;" instead.
With that in mind, it is easier to make someone aware of better
writing functions *without* side-effects, which is supposed to be a
good thing. :-)

BTW, AFAICS and JFTR: C and C++ don't specify evaluation either (I
don't know if Java does fix it), except when sequence points are
involved. The only difference is that unfortunately all Boolean
operations happen to be sequence points here.


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> The philosophy that the semantics of a program should be the same, no
> matter if you choose to write "f := a + b;" or "f = b + a;" instead.

But Ada does not have that philosophy, so that cannot be the reason
to maintain the feature. When "+" is a user-defined subprogram, its
operands are always passed in the order written; a + b is always
invoked as "+"(a, b) and never as "+"(b, a).

> BTW, AFAICS and JFTR: C and C++ don't specify evaluation either

Correct. I've made the same arguments in the C++ newsgroups :-)

> (I don't know if Java does fix it)

It does.

>  The only difference is that unfortunately all Boolean
> operations happen to be sequence points here.

"Unfortunately"? Built-in && is the equivalent of Ada "and then"
and || is the equivalent of "or else". What exactly makes that
unfortunate?

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> The philosophy that the semantics of a program should be the same, no
>> matter if you choose to write "f := a + b;" or "f = b + a;" instead.
>
>But Ada does not have that philosophy, so that cannot be the reason
>to maintain the feature.

It has it for built-in functions where the compiler knows that it
doesn't make any difference.

>When "+" is a user-defined subprogram, its
>operands are always passed in the order written; a + b is always
>invoked as "+"(a, b) and never as "+"(b, a).

Well, yes.

Think of the case where "+" might not be commutative. I guess it would
be too much burden to specify in the standard that the compiler should
be able to figure out if this is the case or not in each particular
case. The simplest example would be a "+" where a and b have different
types. ;-)

>>  The only difference is that unfortunately all Boolean
>> operations happen to be sequence points here.
>
>"Unfortunately"? Built-in && is the equivalent of Ada "and then"
>and || is the equivalent of "or else". What exactly makes that
>unfortunate?

There's no equivalent of an Ada's "and" and "or" where the compiler
can evaluate if the comparison with the result of a costly square-root
function should be delayed until we can figure out if the simple
boolean flag already gives us the result:

|if (Sqrt (x) > 5.0) and b then ...

So you should always write this in the most efficient order then, even
if it might not be the most intuitive way.

BTW, the above is another reason why you shouldn't write functions
with side effects, because if you do the compiler *has* to evaluate
Sqrt, too. :-)


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Hyman Rosen wrote:
> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).

And I should add that the same holds true for associativity. If you
write a + b + c and "+" is user-defined, the call is "+"("+"(a, b), c)
and never "+"(a, "+"(b, c)). The freedom to use other associations is
only for predefined operators.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Think of the case where "+" might not be commutative.

Exactly. So as I said, Ada has no philosophy that a + b
means the same thing as b + a. Thus it is not a relevant
argument against specifying order of evaluation.

> There's no equivalent of an Ada's "and" and "or" where the compiler
> can evaluate if the comparison with the result of a costly square-root
> function should be delayed until we can figure out if the simple
> boolean flag already gives us the result:
> 
> |if (Sqrt (x) > 5.0) and b then ...

How would knowing that b is false help the compiler not call the
costly operation? The rules of Ada require that for "and", both
operands are evaluated! If you are really intent on writing such
code in C or C++, you may say !!a & !!b, where the hideousness
will give a clue to the reader that something weird is going on.

> BTW, the above is another reason why you shouldn't write functions
> with side effects, because if you do the compiler *has* to evaluate
> Sqrt, too. :-)

If the compiler knows enough about Sqrt to know that it has no side
effects, then it will have no problem checking b first even if you
write (sqrt(x) > 5.0 and then b).

Really, all these arguments sound so desperate.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>The rules of Ada require that for "and", both
>operands are evaluated!

No, it doesn't.

>> BTW, the above is another reason why you shouldn't write functions
>> with side effects, because if you do the compiler *has* to evaluate
>> Sqrt, too. :-)
>
>If the compiler knows enough about Sqrt to know that it has no side
>effects, then it will have no problem checking b first even if you
>write (sqrt(x) > 5.0 and then b).

Well, in *this* case you *want* it to be evaluated first, I guess. :)

>Really, all these arguments sound so desperate.

Well, I don't build compilers. But - AFAICS - the only reason for not
fixing the evaluation order usually *is* code optimization.


Vinzent.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But Ada does not have that philosophy, so that cannot be the reason
> to maintain the feature. When "+" is a user-defined subprogram, its
> operands are always passed in the order written; a + b is always
> invoked as "+"(a, b) and never as "+"(b, a).

Absolutely wrong.  If I or any other Ada programmer defines an abstract 
type Foo, and it makes sense to add Integers to Foo, and the semantics 
of addition are commutative, I will declare:

function "+"(L: Foo; R: Integer) return Foo is...

function "+"(L: Integer; R: Foo) return Foo
is begin return R+L; end "+";

This is standard programming practice because it reflects the underlying 
semantics.  In fact I will probably provide "-" operations as well, 
defined as return L+(-R) and R+(-L) respectively.  (And yes, sometimes I 
will even provide an exception handler to deal with subrtracting 
Integer'First..)

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>> 
>> |if (Sqrt (x) > 5.0) and b then ...
>
> How would knowing that b is false help the compiler not call the
> costly operation?

isn't 
   
   if (undecided) and false then 

the same as 

   if false then

?

Only in the case that b is true is the evaluation of needed Sqrt (x) > 5.0 

Or have I missed som point here?


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
>
> If the compiler knows enough about Sqrt to know that it has no side
> effects, then it will have no problem checking b first even if you
> write (sqrt(x) > 5.0 and then b).

Well

if sqrt(x) > 5.0 and then b then

is the same as

if sqrt(x) > 5.0 then
   if b then


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>The rules of Ada require that for "and", both
>>operands are evaluated!
> No, it doesn't.

ARM 4.5/11 says
     "The two operands of an expression of the form X op Y,
      where op is a binary operator, are evaluated in an
      arbitrary order, as for any function_call (see 6.4)."

Where do you find permission for Ada to not evaluate one
operand of an "and" or "or" expression?

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> Only in the case that b is true is the evaluation of needed Sqrt (x) > 5.0 
> Or have I missed som point here?

Sqrt(x) may have side effects.

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Absolutely wrong. ... I will declare...

You are describing your programming practices.
Your practices do not necessarily represent the
philosophy of the language. In any case, when I
said that a + b becomes "+"(a, b) and not "+"(b, a)
I was not "absolutely wrong" but "absolutely right".

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> if sqrt(x) > 5.0 and then b then
> 
> is the same as
> 
> if sqrt(x) > 5.0 then
>    if b then

Yes, so? As I said, if the compiler knows that sqrt(x)
is free of side effects, it can go ahead and evaluate
b first and never call sqrt(x) if b is false.
That's true in both forms above. It doesn't matter how
you write it. If sqrt(x) is free of side effects, you
cannot know whether it has been called, as far as the
language definition is concerned.

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Yes, so? As I said, if the compiler knows that sqrt(x)
> is free of side effects, it can go ahead and evaluate
> b first and never call sqrt(x) if b is false.
> That's true in both forms above. It doesn't matter how
> you write it. If sqrt(x) is free of side effects, you
> cannot know whether it has been called, as far as the
> language definition is concerned.

My point was that when you use the and then you tell the compiler to
evaluate left-side before right. Whereas if you use only and it is not
given which side will be evaluated first. At least I thought so.

-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> My point was that when you use the and then you tell the compiler to
> evaluate left-side before right. Whereas if you use only and it is not
> given which side will be evaluated first. At least I thought so.

Yes, that's correct. However, program behavior is always subject to
the "as if" convention. That is, the program must have observable
behavior as if the compiler did things in the order that the language
specified, but that observable behavior is limited by the language
definition to things like I/O, calling imported subprograms, and some
other stuff that can be loosely categorized as side-effects.

In the proposed case of (sqrt(x) > 0.5 and b), if sqrt(x) has side
effects it must be evaluated regardless of the value of b, and if
it has no side effects you cannot know if it has been evaluated, and
so the compiler may evaluate b first and never evaluate sqrt(x) at
all. The latter holds even if you write (sqrt(x) > 0.5 and then b).

Re: In-Out Parameters for functions

[Frank J. Lhota]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1077727544.813834@master.nyc.kbcfp.com...
> Preben Randhol wrote:
> > Only in the case that b is true is the evaluation of needed Sqrt (x) >
5.0
> > Or have I missed som point here?
>
> Sqrt(x) may have side effects.

For example, if x < 0.0, then Sqrt(x) raises an exception!

Re: In-Out Parameters for functions

[Randy Brukardt]

"Stephen Leake" <stephen_leake@acm.org> wrote in message
news:mailman.20.1077669870.327.comp.lang.ada@ada-france.org...
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

Janus/Ada will take advantage of this to reduce pending floating point
results on the Intel CPUs. These are quite expensive because the floating
point stack is very short, so it has to be clear before any subprogram call.
Thus the pending results have to be spilled to memory (and later reloaded),
rather than just using registers.

So, if you have an expression like:

    B := V + F(...);

Janus/Ada may make the call first, in order to avoid the pending floating
point operation.

Of course, if F changes the value of V, then you'll get a different answer.
Of course, the compiler does not know what's in the body of F. Indeed, even
if it could see the body of F, it couldn't assume that it doesn't modify V,
as it could be changed and recompiled without the call code being changed.

Thus, requiring a particular order of evaluation would make this
optimization impossible. (Even if V is a local variable, it could be changed
by overlays or other nasty code.)

                   Randy.

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1077727496.631820@master.nyc.kbcfp.com...
> ARM 4.5/11 says
>      "The two operands of an expression of the form X op Y,
>       where op is a binary operator, are evaluated in an
>       arbitrary order, as for any function_call (see 6.4)."
>
> Where do you find permission for Ada to not evaluate one
> operand of an "and" or "or" expression?

11.6(5), of course. Since there is no requirement to evaluate a function
solely to see if it raises an exception (since the result is not needed in
this case), the entire call can be removed.

                         Randy.

Re: In-Out Parameters for functions

[Hyman Rosen]

Randy Brukardt wrote:
> "Hyman Rosen" <hyrosen@mail.com> wrote
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
> 
> 11.6(5), of course.

For the particular case of sqrt(x), where we're talking
about Ada's built-in sqrt, and the only possible side-effect
is for it to raise an exception. But if instead we have
(gnurble(x) > 0.5 and b), and the compiler knows that b is
false but has no information about what gnurble does, it
must call gnurble(x) even though the result is irrelevant.

Re: In-Out Parameters for functions

[Jim Rogers]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.20.1077669870.327.comp.lang.ada@ada-france.org>...
> I think Hyman has two valid points:
> 
> 1) if the language specified left-to-right order, there would never be
>    a need to "kill the original smart-ass programmer"
> 
> 2) Does anyone have a real example of a compiler taking advantage of
>    the evaluation order freedom to speed up a program?

But how does his order of evaluation work with named notation?
Is the order determined by the order of the formal parameters, or by
the order of the actual parameters?

In Ada it is not as easy to determine parameter order because of
named notation.

Jim Rogers

Re: In-Out Parameters for functions

[Hyman Rosen]

Jim Rogers wrote:
> But how does his order of evaluation work with named notation?

I would go with the order of the actual parameters,
not the order of the formal parameters. One goal of
specifying evaluation order is to have unsurprising
behavior, so saying
     Battery(Catcher => GetName, Pitcher => GetName);
should assign the first name read to Catcher and the
second to Pitcher, regardless of the order of the formal
parameters of Battery.

I can't at the moment think of a good reason for doing it
the other way from the programmer's point of view, rather
than for the convenience of the compiler.

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-25, Hyman Rosen <hyrosen@mail.com> wrote:
> Randy Brukardt wrote:
>> "Hyman Rosen" <hyrosen@mail.com> wrote
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>> 
>> 11.6(5), of course.
>
> For the particular case of sqrt(x), where we're talking
> about Ada's built-in sqrt, and the only possible side-effect
> is for it to raise an exception. But if instead we have
> (gnurble(x) > 0.5 and b), and the compiler knows that b is
> false but has no information about what gnurble does, it
> must call gnurble(x) even though the result is irrelevant.

Or you have to do:

   value := gnuble(x);

   if value > 0.5 and b then 

to be sure that any side effects are performed.


   with Ada.Text_IO;  use Ada.Text_IO; 

   procedure eval is
      flag : Boolean := false;

      function gnurble(value : Float) return Float is
      begin
         Put_Line ("I was called");
         return value + 99.0;
      end gnurble;

   begin
      if flag and gnurble (1.0) > 2.0 then
   --   if gnurble (1.0) > 2.0 and flag then   -- or this case
   --   if false and gnurble (1.0) > 2.0 then  -- or this
   --   if gnurble (1.0) > 2.0 and false then  -- or this
         Put_Line ("True");
      else
         Put_Line ("False");
      end if;

   end eval;


For all these cases I get that the gnurble function was called and the
if statment is of course false. Even with optimisation.

However if you do this:


   with Ada.Text_IO;  use Ada.Text_IO; 

   procedure eval is
      flag : Boolean := false;

      function gnurble(value : Float) return Float is
      begin
         flag := true;                        -- Added a side effect
         Put_Line ("I was called");
         return value + 99.0;
      end gnurble;

   begin
      if flag and gnurble (1.0) > 2.0 then    -- Case 1 
    --  if gnurble (1.0) > 2.0 and flag then  -- Case 2
         Put_Line ("True");
      else
         Put_Line ("False");
      end if;

   end eval;

The result is:

Case 1:

% ./eval 
I was called
True

Case 2:

% ./eval 
I was called
True

Wheras if you do:

   if flag and then gnurble (1.0) > 2.0 then

then gnurble is never called of course.

Compiler GNAT 3.15p
-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Preben Randhol]

On 2004-02-26, Preben Randhol <randhol+valid_for_reply_from_news@pvv.org> wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.

Note when I say optimisation I only did: gnatmake -O3 
I didn't have time to check the UG for other optimisation flags...


-- 
"Saving keystrokes is the job of the text editor, not the programming
 language."

Re: In-Out Parameters for functions

[Dmitry A. Kazakov]

On Wed, 25 Feb 2004 17:19:50 -0500, Hyman Rosen <hyrosen@mail.com>
wrote:

>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.
>
>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view, rather
>than for the convenience of the compiler.

Discriminants are exposed as members and can be used in named
associations. From any point of view they are better to be evaluated
first:

type Buffer (Size : Integer) is record
   Data : String (1..Size);
end record;

Note that the aggregate:

Buffer'(Data => ..., Size => ...)

is quite legal. So by fixing the evaluation order here the compiler
will be forced to make a temporal copy of the Data field, because it
will be unable to create Buffer not knowing Size.

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

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>The rules of Ada require that for "and", both
>>>operands are evaluated!
>> No, it doesn't.
>
>ARM 4.5/11 says
>     "The two operands of an expression of the form X op Y,
>      where op is a binary operator, are evaluated in an
>      arbitrary order, as for any function_call (see 6.4)."
>
>Where do you find permission for Ada to not evaluate one
>operand of an "and" or "or" expression?

In "arbitrary"? ;-)


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>For the particular case of sqrt(x), where we're talking
>about Ada's built-in sqrt, and the only possible side-effect
>is for it to raise an exception. But if instead we have
>(gnurble(x) > 0.5 and b), and the compiler knows that b is
>false but has no information about what gnurble does, it
>must call gnurble(x) even though the result is irrelevant.

Yes, it should (I'm not sure, if it actually *has to*) call the
function if it is possible that the function has side-effects.

What's your problem here?


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Jim Rogers wrote:
>> But how does his order of evaluation work with named notation?
>
>I would go with the order of the actual parameters,
>not the order of the formal parameters. One goal of
>specifying evaluation order is to have unsurprising
>behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
>should assign the first name read to Catcher and the
>second to Pitcher, regardless of the order of the formal
>parameters of Battery.

Yes, and that is a very good example on how to write bad code. First:
GetName is obviously a function with side-effect, second it relies on
a specific calling order.

If you want a specific order, do it explicitely:

|Tmp_Name_1 := GetName;
|Tmp_Name_2 := GetName;
|
|Battery(Catcher => Tmp_Name_1, Pitcher => Tmp_Name_2);

>I can't at the moment think of a good reason for doing it
>the other way from the programmer's point of view,

Well, my point of view to the original code would be that it doesn't
matter which name gets assigned to which parameter.

>rather than for the convenience of the compiler.

Yes, true. But Ada is - like a lot of others - a programming language
that is supposed to get compiled some day. And sometimes language
designers should keep an eye on this if they want a language to be
used outside of purely theoretical and/or educational areas.

So it might be possible that in the parsing/compiling process the
order specified in the named notation simply gets reordered to the
order of how the parameters are declared. Well, even this still
doesn't mean, that this would be the order in which the functions are
called in the end.

I think, all this discussion about execution order is a little bit
senseless when today we have processors that do explicit instruction
reordering and even have parallel execution support. Even if the
compiler issues code where the execution order is fixed that doesn't
mean that the processor will execute it this way. And you don't want
the compiler to emit one serializing instruction after another just to
make sure that the execution order does not change, do you?

IMO, it is easier to just not rely on side-effects. No side-effects,
no problems.


Vinzent.

Re: In-Out Parameters for functions

[Wojtek Narczynski]

Hello,

> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
>      Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.

How about:

Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName
);

This way the change would not affect current code, and you could
specify partial order.

Regards,
Wojtek

Re: In-Out Parameters for functions

[Lutz Donnerhacke]

* Wojtek Narczynski wrote:
> How about:
> Battery(Catcher => GetName then Pitcher => GetName, Doorman => GetName);

Very bad. Hard to read. Hard to maintain. Bad Ada-Style.

   declare
      catcher : constant Name := GetName;
      pitcher : constant Name := GetName;
      doorman : constant Name := GetName;
   begin
      Battery(catcher, pitcher, doorman);
   end;

Moderate to write, moderate to read and easy to understand/maintain.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Vinzent 'Gadget' Hoefler wrote:

> Hyman Rosen wrote:
> 
>> For the particular case of sqrt(x), where we're talking about Ada's
>> built-in sqrt, and the only possible side-effect is for it to raise
>> an exception. But if instead we have (gnurble(x) > 0.5 and b), and
>> the compiler knows that b is false but has no information about
>> what gnurble does, it must call gnurble(x) even though the result
>> is irrelevant.
> 
> 
> Yes, it should (I'm not sure, if it actually *has to*) call the 
> function if it is possible that the function has side-effects.
> 
> What's your problem here?
> 

That he has never read 10.2.1(18)? "If a library unit is declared pure,
then the implementation is permitted to omit a call on a library-level 
subprogram of the library unit if the results are not needed after the 
call. Similarly, it may omit such a call and simply reuse the results 
produced by an earlier call on the same subprogram, provided that none 
of the parameters are of a limited type, and the addresses and values of 
all by-reference actual parameters, and the values of all by-copy-in 
actual parameters, are the same as they were at the earlier call. This 
permission applies even if the subprogram produces other side effects 
when called."

Can't we just all agree that Hymen is not an Ada language expert and 
doesn't want to be?  In this case, the rules of Ada are well thought out 
to allow any user, not the compiler to determine whether an 
"unnecessary" function call can be eliminated.  Similarly, the language 
allows users to force syncronization points and orders of evaluation, 
when they are a necessary part of the algorithm being implemented.

We have jokingly called for shooting a programmer who knowingly writes 
code that depends on order of evaluation and then--yes that is an Ada 
and then--doesn't document it or force the compiler to use the necessary 
order.   Actually the correction applied would probably be education, 
warnings, bad reviews, and eventually firing the employee if nececssary.

For anyone who deliberately persists in such bad habits, if necessary 
could be within weeks. Emphasis on deliberately, but I have had to make 
that decision for programmers who persisted in other bad habits like 
bypassing the required check-in procedures for software. In that case, 
firing the programmer probably saved him from a lynch mob, as other 
programmmers kept finding their submissions being rejected due to his 
changes not passing the regression tests.

What do we do with Mr. Hymen Rosen?  For now, I'm going to just post 
chapter and verse, and that Mr. Rosen's opinion on any Ada language 
issue should be ignored.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Preben Randhol wrote:
> 
>> Only in the case that b is true is the evaluation of needed Sqrt (x) > 
>> 5.0 Or have I missed som point here?
> 
> 
> Sqrt(x) may have side effects.

Totally irrelevant.  As I just posted what matters is whether or not 
Sqrt(x) is declared in a pure library unit.  In the case of the standard 
Sqrt, the standard also says:

    pragma Pure(Generic_Elementary_Functions);

So the compiler is free to eliminate calls to Sqrt if possible.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
> 
>> Absolutely wrong. ... I will declare...
> 
> 
> You are describing your programming practices.
> Your practices do not necessarily represent the
> philosophy of the language. In any case, when I
> said that a + b becomes "+"(a, b) and not "+"(b, a)
> I was not "absolutely wrong" but "absolutely right".

No, you were absolutely wrong as usual.  The order of evaluation of the 
parameters to "+" is undefined whether the "+" is user defined or 
language defined.  To quote 6.4(10): "These evaluations are done in an 
arbitrary order."  There is even an explicit footnote at 4.5(14) that 
explains that this applies to predefined operators as well as user 
defined operators.

I should stop wrestling with pigs.  But I would like to preserve this 
newsgroup as a place where users can get reliable advice on language 
issues.  So I have to keep putting up these placards that say ignore 
anything Hyman Rosen says about Ada language issues.

-- 

                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Jim Rogers wrote:
> 
>> But how does his order of evaluation work with named notation?
> 
> 
> I would go with the order of the actual parameters,
> not the order of the formal parameters. One goal of
> specifying evaluation order is to have unsurprising
> behavior, so saying
>     Battery(Catcher => GetName, Pitcher => GetName);
> should assign the first name read to Catcher and the
> second to Pitcher, regardless of the order of the formal
> parameters of Battery.
> 
> I can't at the moment think of a good reason for doing it
> the other way from the programmer's point of view, rather
> than for the convenience of the compiler.

You can't but Randy posted a very good explanation of why his compiler 
does it in a different order.  And even at the risk of sounding like a 
broken record, the Ada standard say this will be done in "an arbitrary 
order."  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.

-- 

                                           Robert I. Eachus


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

Re: In-Out Parameters for functions

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 578 bytes --]


"Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
> What do we do with Mr. Hymen Rosen?  For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.
>
Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
people :-)

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: In-Out Parameters for functions

[Hyman Rosen]

Preben Randhol wrote:
> For all these cases I get that the gnurble function was called and the
> if statment is of course false. Even with optimisation.

We're in violent agreement here. Everything you report is
exactly how I exepcted it to be. (Except for the case of
the gnurble which modifies the flag, where I don't have any
expectations.)

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Vinzent 'Gadget' Hoefler wrote:
>> What's your problem here?
> That he has never read 10.2.1(18)?
> Can't we just all agree that Hyman is not an Ada language expert and 
> doesn't want to be? ... What do we do with Mr. Hyman Rosen?  For now,
 > I'm going to just post chapter and verse, and that Mr. Rosen's opinion
 > on any Ada language issue should be ignored.

This particular subthread started when V'G'H stated that in C/C++
     "The only difference is that unfortunately all Boolean
      operations happen to be sequence points here."
When I asked him why this was unfortunate, he replied that the Ada
     if (Sqrt (x) > 5.0) and b then
permitted Ada to test b first, and not call Sqrt(x) if b was false.
I pointed out that unless sqrt(x) (later amended to gnurble(x)) was
known to the compiler to be free of side-effects, the compiler must
call it regardless of the value of b. I also pointed out that under
similar circumstances
     if (Sqrt (x) > 5.0) and then b then
would allow exactly the same optimization to be performed, i.e., b
could be tested first and sqrt(x) need not be called if b is false.
I assume 10.2.1(18)'s "results are not needed" allows the compiler
to be as brilliant as it wants to be in determining this?

In these discussions I tend to use the phrase "free of side-effects"
as shorthand. I know that prgama pure subprograms are permitted to
have side-effects, but that's not germane to the discussion, and I
don't feel like adding "or pure" all over the place.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Hyman Rosen wrote:
>>Where do you find permission for Ada to not evaluate one
>>operand of an "and" or "or" expression?
> 
> In "arbitrary"? ;-)

Being permitted to do some things in arbitrary order certainly
does not give permission to omit doing some of them. The ARM
does not say that an arbitrary number of operands are evaluated,
it says that the operands are evaluated in arbitrary order.

This is not Wonderland, where words mean exactly what you want
them to.

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Hyman Rosen wrote:
>> In any case, when I
>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>> I was not "absolutely wrong" but "absolutely right".
> 
> No, you were absolutely wrong as usual.  The order of evaluation of the 
> parameters to "+" is undefined whether the "+" is user defined or 
> language defined.

Where did I say that the order of evaluation of the operands was
defined? V'G'H argued that the philosophy of Ada was that a + b
and b + a are the same. I pointed out that for user-defined "+",
when you write a + b, the function is called with a as the Left
operand and b as the Right, never the reverse.

 > I should stop wrestling with pigs.

You are so eager to believe I am wrong about everything I say that
you are not reading what I say. Stop it. You're just going to annoy
the pig :-)

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Yes, and that is a very good example on how to write bad code. First:
> GetName is obviously a function with side-effect, second it relies on
> a specific calling order.

Well, duh. The discussion is about what behavior we want in this case
should we actually define a specific calling order.

> I think, all this discussion about execution order is a little bit
> senseless when today we have processors that do explicit instruction
> reordering and even have parallel execution support.

Not at all. We are discussing the semantics of Ada. How they are
implemented on a processor by the compiler is not relevant.

Re: In-Out Parameters for functions

[Hyman Rosen]

Lutz Donnerhacke wrote:
> Very bad. Hard to read. Hard to maintain. Bad Ada-Style.
>    declare
>       catcher : constant Name := GetName;
>       pitcher : constant Name := GetName;
>       doorman : constant Name := GetName;
>    begin
>       Battery(catcher, pitcher, doorman);
>    end;
> Moderate to write, moderate to read and easy to understand/maintain.

Or, in well-defined Ada,
     declare
         catcher, pitcher, doorman : constant Name := GetName;
     begin
        Battery(catcher, pitcher, doorman);
     end;

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
 > Randy posted a very good explanation of why his compiler
> does it in a different order.

Yes. That was finally a legitimate example of the compiler
using this permission to generate better code.

> But it is much harder to do that than to make the 
> code agnostic about evaluation order, and that is intentional.

But unlike such things as array index violations, Ada isn't
required to tell you that your code is not agnostic about
evaluation order, and therefore such violations can lurk
undetected.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Hyman Rosen wrote:
>>>Where do you find permission for Ada to not evaluate one
>>>operand of an "and" or "or" expression?
>> 
>> In "arbitrary"? ;-)
>
[Disagreement]

>This is not Wonderland, where words mean exactly what you want
>them to.

Should I have marked the Smiley Red and with an additional
"blink"-Attribute? Perhaps some alarming sound, too?


Vinzent.

Re: In-Out Parameters for functions

[Vinzent 'Gadget' Hoefler]

Hyman Rosen wrote:

>Vinzent 'Gadget' Hoefler wrote:
>> Yes, and that is a very good example on how to write bad code. First:
>> GetName is obviously a function with side-effect, second it relies on
>> a specific calling order.
>
>Well, duh. The discussion is about what behavior we want in this case
>should we actually define a specific calling order.

Yes. But I don't like the idea of inviting programmers to a party "We
have defined the evaluation order - now you can write functions with
side-effects and they behave equally strange on all systems".

>> I think, all this discussion about execution order is a little bit
>> senseless when today we have processors that do explicit instruction
>> reordering and even have parallel execution support.
>
>Not at all. We are discussing the semantics of Ada. How they are
>implemented on a processor by the compiler is not relevant.

It just doesn't make sense to argue about a specific order if the
processor itself changes it when the code gets executed, does it?


Vinzent.

Re: In-Out Parameters for functions

[Hyman Rosen]

Vinzent 'Gadget' Hoefler wrote:
> Yes. But I don't like the idea of inviting programmers to a party "We
> have defined the evaluation order - now you can write functions with
> side-effects and they behave equally strange on all systems".

The idea is to make it not strange, so that you read the code and
immediately understand what it does.

> It just doesn't make sense to argue about a specific order if the
> processor itself changes it when the code gets executed, does it?

Of course it does, in the same way that we can talk about Ada's
support for decimal arithmetic on processors which are unrelentingly
binary. Programming langiage semantics don't have anything to do
with processor semantics.

Re: In-Out Parameters for functions

[David Starner]

On Thu, 26 Feb 2004 13:12:32 -0500, Hyman Rosen wrote:
> The idea is to make it not strange, so that you read the code and
> immediately understand what it does.

Part of the point of the argument is that I don't believe your solution
can change; it's still going to be virtually impossible to follow, it's
just going to be sanctioned as acceptable.

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> <snip 10.2.1 (18)> 
> 
> Can't we just all agree that Hymen is not an Ada language expert and
> doesn't want to be?  

I don't think that is a fair characterization of Hymen's discussions.

> In this case, the rules of Ada are well thought out to allow any
> user, not the compiler to determine whether an "unnecessary"
> function call can be eliminated. Similarly, the language allows
> users to force syncronization points and orders of evaluation, when
> they are a necessary part of the algorithm being implemented.

Hymen is asking about the value of these rules _in practice_, and
attempting to discuss whether a slightly different set of rules might
be better for Ada.

In particular, are there any _actual compilers_ that take advantage of
the freedom given by 10.2.1 (18)?

> We have jokingly called for shooting a programmer who knowingly
> writes code that depends on order of evaluation and then--yes that
> is an Ada and then--doesn't document it or force the compiler to use
> the necessary order. Actually the correction applied would probably
> be education, warnings, bad reviews, and eventually firing the
> employee if nececssary.
> 
> For anyone who deliberately persists in such bad habits, if necessary
> could be within weeks. Emphasis on deliberately, but I have had to
> make that decision for programmers who persisted in other bad habits
> like bypassing the required check-in procedures for software. In that
> case, firing the programmer probably saved him from a lynch mob, as
> other programmmers kept finding their submissions being rejected due
> to his changes not passing the regression tests.

True. And appropriate for any bad habit.

But not relevant here. The question is "would a slightly different
rule be better for Ada". Not "what are the current rules of Ada".
Although it is true that some people in this discussion need
refreshers on that ...

> What do we do with Mr. Hymen Rosen? For now, I'm going to just post
> chapter and verse, and that Mr. Rosen's opinion on any Ada language
> issue should be ignored.

ok. 

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > But Ada does not have that philosophy, so that cannot be the reason
> > to maintain the feature. When "+" is a user-defined subprogram, its
> > operands are always passed in the order written; a + b is always
> > invoked as "+"(a, b) and never as "+"(b, a).
> 
> Absolutely wrong.  

That's an odd thing to say! 

> If I or any other Ada programmer defines an abstract type Foo, and
> it makes sense to add Integers to Foo, and the semantics of addition
> are commutative, I will declare:
> 
> function "+"(L: Foo; R: Integer) return Foo is...

Let's call this function 1.

> function "+"(L: Integer; R: Foo) return Foo is begin return R+L; end
> "+";

and function 2.

Yes. and the reason you need to do this is that the Ada _language_
requires that 'a + b' _always_ be equivalent to "+" (a, b), not "+"
(b, a), as Hymen said!

To be more concrete:
declare
   a : Foo;
   b : Integer;
   c : integer;
   d : integer;
begin
   c := a + b; -- calls function 1
   d := b + a; -- calls function 2
end;

If Ada were allowed to use "+" (b, a) for 'a + b', you would not need
function 2 to compute d.

-- 
-- Stephe

Re: In-Out Parameters for functions

[Stephen Leake]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> You can't but Randy posted a very good explanation of why his compiler
> does it in a different order.  And even at the risk of sounding like a
> broken record, the Ada standard say this will be done in "an arbitrary
> order."  

Hymen is trying to discuss a change to that Ada rule. Repeating what
the current Ada rules say is not helpful.

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

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

-- 
-- Stephe

Re: In-Out Parameters for functions

[David Starner]

On Fri, 27 Feb 2004 00:21:25 -0500, Stephen Leake wrote:
> In particular, are there any _actual compilers_ that take advantage of
> the freedom given by 10.2.1 (18)?

Yes. In <103q25acc6knm97@corp.supernews.com>, in a reply to this same
comment of yours, Randy Brukardt pointed out that Janus/Ada will take
advantage of this, and why.

Re: In-Out Parameters for functions

[Randy Brukardt]

"Vinzent 'Gadget' Hoefler" <nntp-2004-02@t-domaingrabbing.de> wrote in
message news:t9fr30tnl8rh0ain01qeqq17ottovqdso3@jellix.jlfencey.com...
...
> So it might be possible that in the parsing/compiling process the
> order specified in the named notation simply gets reordered to the
> order of how the parameters are declared.

Right. That's exactly what Janus/Ada does internally for named notation, and
the arguments are evaluated in the order that they get passed; no matter
what order they were passed in.

> IMO, it is easier to just not rely on side-effects. No side-effects, no
problems.

Which was the basic idea behind Pure - a way to declare that functions have
no meaningful side effects. (Caching values and records calls in a
scratchpad aren't meaningful). It's unfortunate that applying the "Pure"
categorization is so difficult. GNAT provides a solution here - pragma
Pure_Function - which essentially declares to the compiler that the function
has no meaningful side effects without any checks. (This pragma is being
considered for Ada 200Y.) One could imagine a coding standard which required
all functions used in non-trivial expressions (that is, not used alone) to
be marked either Pure or Pure_Function.

                    Randy.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Jean-Pierre Rosen wrote:

> "Robert I. Eachus" <rieachus@comcast.net> a �crit dans le message de news:-tednUSWDcMxbqDdRVn-sw@comcast.com...
> 
>>What do we do with Mr. Hymen Rosen?  For now, I'm going to just post
>>chapter and verse, and that Mr. Rosen's opinion on any Ada language
>>issue should be ignored.

> Please always use qualified notation (with the first-name). Otherwise, a partial quotation of the above would overload several
> people :-)

Good point, I explicitly qualified the first reference for just that 
reason--that the paragraph might be quoted out of context.  I probably 
should have either used "his" or a full name for the second reference as 
well.

As you well know, of course, it is very hard to write something that 
doesn't sound stilted, and still stands up to hostile (mis-)interpretation.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Robert I. Eachus wrote:
> 
>> Hyman Rosen wrote:
>>
>>> In any case, when I
>>> said that a + b becomes "+"(a, b) and not "+"(b, a)
>>> I was not "absolutely wrong" but "absolutely right".
>>
>>
>> No, you were absolutely wrong as usual.  The order of evaluation of 
>> the parameters to "+" is undefined whether the "+" is user defined or 
>> language defined.
> 
> 
> Where did I say that the order of evaluation of the operands was
> defined? V'G'H argued that the philosophy of Ada was that a + b
> and b + a are the same. I pointed out that for user-defined "+",
> when you write a + b, the function is called with a as the Left
> operand and b as the Right, never the reverse.
> 
>  > I should stop wrestling with pigs.
> 
> You are so eager to believe I am wrong about everything I say that
> you are not reading what I say. Stop it. You're just going to annoy
> the pig :-)

No, it is trying to teach a pig to sing that annoys the pig.  When you 
wrestle with pigs, you just get dirty, and the pig enjoys it.  (Of 
course, if the pig is a pet and kept clean, the person doing the 
wrestling may stay clean and actually want the pig to enjoy it.)  But 
this is not a discussion of ENGLISH semantics ;-)

MY point, which apparently you missed, was not that Ada compilers are 
allowed to ignore the order of parameters (except of course with named 
notation). It is that you will find lots of places in the standard where 
order independent SEMANTICS occurs, for example in 13.7.1(7).  In those 
cases the usual implementation (in this case of package 
System.Storage_Elements) will simplify things by using parameter 
flipping and pragma Inline.  If we were to change the semantics of Ada 
to require left-to-right evaluation, what should be done with these 
functions, especially when they are in-lined?  A workable rule probably 
could be written, but it is the sort of thing you have to look at with a 
proposal like yours.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> But unlike such things as array index violations, Ada isn't
> required to tell you that your code is not agnostic about
> evaluation order, and therefore such violations can lurk
> undetected.

No matter how hard we try, it is not always possible for a compiler to 
read the programmer's mind.  So there will always be bugs that exist 
only in the author's mind.  If I write:

X := X + 10;

But I actually intended to decrement X, the compiler can't catch that. 
In fact on some other day, I might write identical code and expect X to 
be incremented.  (In fact what probably happened was that I did a sloppy 
cut-and-paste, but ignore that for now.)

Compilers can notice suspicious code, and warn the author.  For example, 
if I had written:

X := X + 0;

A good compiler might warn me that the assignment statement resulted in 
no code being generated, and that might lead me to find MY bug.  But 
bugs are always a matter of definition.  That is why I like the style of 
programming where I start with a list of requirements, and the code is 
expected to implement those requirements exactly.  That way the judgment 
of whether or not something is a bug is objective, not personal. 
(Doesn't stop me from considering "poorly formatted output" to be a 
valid bug report.)

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
>  It is that you will find lots of places in the standard where
> order independent SEMANTICS occurs, for example in 13.7.1(7).  In those 
> cases the usual implementation (in this case of package 
> System.Storage_Elements) will simplify things by using parameter 
> flipping and pragma Inline.  If we were to change the semantics of Ada 
> to require left-to-right evaluation, what should be done with these 
> functions, especially when they are in-lined?  A workable rule probably 
> could be written, but it is the sort of thing you have to look at with a 
> proposal like yours.

The section to which you refer defines a pair of "+" operations.
I don't see how they cause any issues for l-to-r. And pragma Inline
does not affect the semantics of a program, so again I don't see what
the relevance is. I do agree that there seem to be unholy complexities
lurking in the trade-offs between checking requirements and allowing
optimization which could be exacerbated by requiring l-to-r.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> The section to which you refer defines a pair of "+" operations.
> I don't see how they cause any issues for l-to-r. And pragma Inline
> does not affect the semantics of a program, so again I don't see what
> the relevance is. I do agree that there seem to be unholy complexities
> lurking in the trade-offs between checking requirements and allowing
> optimization which could be exacerbated by requiring l-to-r.

You are getting there.  Bob Mathis once told me a Lisp joke:

(defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1))

That really sums up the issue I was bringing up. The second function in 
that particular pair of functions is probably defined by:

  function "+"(Left : Storage_Offset; Right : Address) return Address is
  begin return Right + Left; end "+";
  -- with pragma Inline in the spec.

Now, when do you apply your left-to-right requirement, before or after 
the pragma Inline has been applied?  Since the pragma Inline probably 
applies to both calls, I guess the answer has to be before the inlining.

Thinking some more about your proposal, now that I have looked at it 
from all sides, a much more modest version  seems reasonable: If an 
expression contains two non-pure, non-predefined functions they must be 
evaluated in canonical order instead of "some order."  This would allow 
compilers to do all their code motion in most cases, and only 
expressions with two or more impure function calls would need to switch 
off some of those optimizations.  You could probably modify GNAT to 
check the effects of that rule change out if you wanted to.  (Or ask 
your compiler vendor to put in a switch--the result of turning on the 
switch would still be a legal implementation of Ada.  Not that there is 
a requirement that compiler switches work that way.)

Personally, as I said, I have written code that has to handle 
Constraint_Error in some cases, and reraise it in others.  In those 
cases, for Ada 95, I not only have to break some expressions into two 
parts, but insure that the parts are covered by different exception 
handlers--in different packages.  It is a pain to get that code right 
according to the (current) Ada 95/2000 rules, but I don't think your 
change would help.  It is the permission in the last sentence of 11.6(6) 
that is the real issue.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Jon S. Anthony]

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Hyman Rosen wrote:
> 
> > The section to which you refer defines a pair of "+" operations.
> > I don't see how they cause any issues for l-to-r. And pragma Inline
> > does not affect the semantics of a program, so again I don't see what
> > the relevance is. I do agree that there seem to be unholy complexities
> > lurking in the trade-offs between checking requirements and allowing
> > optimization which could be exacerbated by requiring l-to-r.
> 
> You are getting there.  Bob Mathis once told me a Lisp joke:
> 
> (defun twiddle-thumbs thumb1 thumb2 (twiddle-thumbs thumb2 thumb1))

???  This is ill formed Common Lisp.  Presumably you mean:

(defun twiddle-thumbs (thumb1 thumb2)
  (twiddle-thumbs thumb2 thumb1))

Which if called, say by:

...
  (twiddle-thumbs l-thumb r-thumb)
...

will produce an infinite loop (and thus the "joke" part).

BTW, Lisp _does_ require l-to-r argument evaluation in calls.


> That really sums up the issue I was bringing up. The second function
> in that particular pair of functions is probably defined by:

I'm fairly sure you are referring to the pair of functions mentioned
in HR's comment, but just so no one else gets confused: There is only
one function in the Lisp given, not two.


>   function "+"(Left : Storage_Offset; Right : Address) return Address is
>   begin return Right + Left; end "+";
>   -- with pragma Inline in the spec.
> 
> Now, when do you apply your left-to-right requirement, before or after
> the pragma Inline has been applied?  Since the pragma Inline probably
> applies to both calls, I guess the answer has to be before the
> inlining.

It's irrelevant as you (the compiler writer) simply arrange to have
the arguments evaluated in the correct order and then passed.  Here is
an implementation of such a pair (in Lisp, since you can do this sort
of stuff at the user/programmer level):

(defmacro +one (l r)
  `(+ ,l ,r))

(defmacro +two (l r)
  (with-gensyms (ul ur)
    `(let ((,ul ,l) ; evaluate l
	   (,ur ,r)); evaluate r
       (+one ,ur ,ul))))


This is semantically (at compilation level semantics) the same as:

(defun +one (l r)
  (+ l r))

(defun +two (l r)
  (+one r l))

(declaim (inline +one +two))


What gets generated at a call in some code:

(macroexpand-1 '(+one (sqrt 8) (expt 2 32)))
   ==> (+ (sqrt 8) (expt 2 32))

(macroexpand-1 '(+two (sqrt 8) (expt 2 32)))
   ==>
(LET ((#:G87115 (SQRT 8)) (#:G87116 (EXPT 2 32)))
  (+ONE #:G87116 #:G87115))

(macroexpand '(+two (sqrt 8) (expt 2 32))) ; Fully expand
   ==>
(LET ((#:G87135 (SQRT 8)) (#:G87136 (EXPT 2 32)))
  (+ #:G87136 #:G87135))


(+two (sqrt 8) (expt 2 32))
   ==> 4.2949673e+9


So, arguments to both are always evaluated in the correct order, even
though one compiles directly inline to a call of the other which is
also compiled inline.  No big deal.



/Jon

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> Now, when do you apply your left-to-right requirement, before or after 
> the pragma Inline has been applied?

Pragma Inline is not exactly "applied". It is a hint to the compiler
that it would be advantageous for certain code to be expanded inline
as opposed to being called through the "normal" subprogram mechanism.
It does not have any effect on the meaning of Ada code which uses such
a subprogram, and therefore would not have any meaning when considering
l-to-r behavior.

> If an expression contains two non-pure, non-predefined functions they
 > must be evaluated in canonical order instead of "some order."

This gets you most of the way there. It would still leave pathological
cases like (I + Inc(I)) unspecified, but I can't imagine that there's
any real code out there which cares.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> Pragma Inline is not exactly "applied". It is a hint to the compiler
> that it would be advantageous for certain code to be expanded inline
> as opposed to being called through the "normal" subprogram mechanism.
> It does not have any effect on the meaning of Ada code which uses such
> a subprogram, and therefore would not have any meaning when considering
> l-to-r behavior.

There you go again.  What you say seems to make sense, but it is not 
correct.  To quote from 11.6(6):  "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."

So although whether the compiler does follow the advice of a pragma 
Inline, it has semantic effects.  Those effects happen to be important 
in this particular case.  The appearance of an independent subprogram 
prevents the compiler from doing some reorderings.  Put in the pragma 
Inline, and the code might not be inlined by the compiler, but the 
compiler could move other code from before to after it or vice-versa.


-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Hyman Rosen]

Robert I. Eachus wrote:
> So although whether the compiler does follow the advice of a pragma 
> Inline, it has semantic effects.

The same section says
     "The permissions granted by this clause can have an effect on the
      semantics of a program only if the program fails a language-defined
      check."

So unless you're coding in a way where you expect to cause and catch
l-d checks, it won't matter.

Also, if I read that section correctly, in a sequence of code like this
     a := 0;
     b := c + d;
     e := f + g;
     h := i + j;
     a := 1 / a;
it is possible that only the assignment to a will have occurred when the
exception handler from the division by zero is executed, is that correct?
Doesn't that make catching failures of language-defined checks useless?
You will know that something bad happened, but you won't know which objects
in your program are abnormal.

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:

> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.

Yes (assuming your functions haven't got side effects).

> Also, if I read that section correctly, in a sequence of code like
> this
>      a := 0;
>      b := c + d;
>      e := f + g;
>      h := i + j;
>      a := 1 / a;
> it is possible that only the assignment to a will have occurred when
> the exception handler from the division by zero is executed, is that
> correct?

I _think_ (haven't got the ARM around right now) that in case the
object b, e and h aren't accessible/used after the exception has been
raised, you are correct that the only thing that actually happens in
the following statements is that an exception is raised by the
division by zero.  This view is based on the principle of �same
external effect�.

If b, e or h on the other hand is accessible/used after the exception
has been raised, then the (or some of the) three intermediate
statements have to be executed as well to give the same external
effect.

> Doesn't that make catching failures of language-defined checks
> useless?  You will know that something bad happened, but you won't
> know which objects in your program are abnormal.

No.  You should know from the sequence the statements are written in,
which statements have been executed if it has an effect on which of
the _accessible_ objects are in which state.

Jacob (who isn't a LL and didn't look it up in the ARM)
-- 
�What fun is it being "cool" if you can't wear a sombrero?�

Re: In-Out Parameters for functions

[Hyman Rosen]

Jacob Sparre Andersen wrote:
> No.  You should know from the sequence the statements are written in,
> which statements have been executed if it has an effect on which of
> the _accessible_ objects are in which state.

I don't think so, given 11.6(6).

Re: In-Out Parameters for functions

[Jacob Sparre Andersen]

Hyman Rosen wrote:
> Jacob Sparre Andersen wrote:

> > No.  You should know from the sequence the statements are written
> > in, which statements have been executed if it has an effect on
> > which of the _accessible_ objects are in which state.
> 
> I don't think so, given 11.6(6).

Right!

But if this really is a serious problem for you, you can handle it by
putting each of the five assignments in your sequence of statements
within its own begin-exception-end block.  Assuming that I have
understood 11.6(6) correctly by now.

Jacob
-- 
"Those who profess to favor freedom and yet depreciate
 agitation, are people who want crops without ploughing the
 ground; they want rain without thunder and lightning; they
 want the ocean without the roar of its waters."
                                        -- Frederick Douglas

Re: In-Out Parameters for functions

[Hyman Rosen]

Jacob Sparre Andersen wrote:
> But if this really is a serious problem for you, you can handle it by
> putting each of the five assignments in your sequence of statements
> within its own begin-exception-end block.

That's not really the point. If I know in micro-detail where a check
is failing, I could just as easily make it not fail. What I expected
(which will probably earn me another blast from RE for not getting
the Ada mindset) was that the reason for l-d checks is to prevent the
kind of errors you find in C, namely undetected erroneous changes that
trigger problems at some remove from the place where they occurred.
It seems to me that the Ada rules allow the same sort of thing to
happen - if I have a handler at a high level for a language-defined
error, it's possible that any number of objects may have been left in
an abnormal state when the exception triggered, and I will encounter
erroneous (and possibly undetected) behavior at some later point.

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> The same section says
>     "The permissions granted by this clause can have an effect on the
>      semantics of a program only if the program fails a language-defined
>      check."
> 
> So unless you're coding in a way where you expect to cause and catch
> l-d checks, it won't matter.

Exactly correct.  But I do write code that deals with Constraint_Error, 
and has to do so correctly--whatever that means in that particular library.

> Also, if I read that section correctly, in a sequence of code like this
>     a := 0;
>     b := c + d;
>     e := f + g;
>     h := i + j;
>     a := 1 / a;
> it is possible that only the assignment to a will have occurred when the
> exception handler from the division by zero is executed, is that correct?
> Doesn't that make catching failures of language-defined checks useless?
> You will know that something bad happened, but you won't know which objects
> in your program are abnormal.

In fact for this sequence the compiler can generate code that does no 
assignments and always raises Constraint_Error.  I wrote a little program:

with Ada.Text_IO; use Ada.Text_IO;
procedure Hyman_Example is
   A,B,C,D,E,F,G,H,I,J: Integer := 1;
begin
   begin
     a := 0;
     b := c + d;
     e := f + g;
     h := i + j;
     a := 1 / a;
   exception when Constraint_Error =>
     Put_Line("Constraint_Error Raised. a = " & Integer'Image(A)
         & " b = " & Integer'Image(B)
         & " e = " & Integer'Image(E)
         & " h = " & Integer'Image(H));
   end;
end Hyman_Example;

And was actually surprised that GNAT didn't give me a warning and do 
just that.  I suspect that GNAT was being 'nice' because it saw a 
declare block there to handle Constraint_Error.  I could try making the 
declare block a library unit procedure and see what happens.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: And was actually surprised that GNAT didn't give me a warning and do 
: just that.

Maybe I just haven't understood, however:
Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)

    11.      a := 1 / a;
                    |
        >>> warning: division by zero
        >>> warning: "Constraint_Error" will be raised at run time

 18 lines: No errors, 2 warnings

(further warnings about C, D, F, G, I, J not being modified
but not declared constant, if requested.)

Re: In-Out Parameters for functions

[Robert I. Eachus]

Hyman Rosen wrote:

> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail. What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

First of all, on this point I agree with you that the Ada 95 rules go 
too far.  Fortunately, if you look at the example I posted, most Ada 
compilers are very careful about taking advantage of the 11.6(6) 
freedoms when exceptions can happen.

The real problem is that it is very hard to write a rule that makes 
sense given the way today's CPUs are built.  The CPU will reorder 
instructions at run-time, and only some CPUs will pretend, if an 
instruction causes an interrupt, that the ordering was precise.  I could 
probably reference half a dozen architecture manuals for you, that 
detail exactly how precise and non-precise interrupts are serviced.  But 
it is lots of really boring trivia to sort through to figure out what 
happens in a case that you might care about.  But I do read those 
manuals, thoroughly at least for most SPARC family processors, x86 
processors and now AMD64/IA-32e CPUs.

You have to remember is that the implementations vary, even within a 
processor family, and worse some processors have multiple modes, with 
different interrupt behavior.  So the current (Ada 95) RM rules really 
amount to do what makes sense on the real hardware--because the compiler 
compiles to an ISA, and for many ISAs, the rules change from 
implementation to implementation.

Fortunately, as the program I just posted shows, most compilers still 
obey the old Ada 83 meta-rule:  "Thou shalt not reason from 
erroneousness."  The program as written is (intentionally) erroneous. 
Not causes a bounded error, which is a much more tightly limited case, 
but erroneous.

Would I write code like that 'for real'?  Of course not.  But it doesn't 
prevent me from grumbling about how difficult it can be for a programmer 
to avoid erroneousness in some contexts.

(Technically what you have to do is write subprograms that handle 
exceptions internally as follows:

procedure Foo(...) is
   -- object declarations here should never raise an exception.
   -- put things that can in a nested block.
begin
   declare
      -- potentially problematical variables
   begin
      -- do any additional checking here, but don't assign to any
      -- out or in out parameters.

      -- firewall This is usually a call to some external procedure or
      -- function that is not inlined.  This can be, and often is in
      -- code that I write, a call that is needed anyway.

      -- do any assignments to globals or parameters here.
   exception
      when Constraint_Error =>
      -- fix the problem either by using a different
      -- algorithm, or by a nested call to Foo with modified parameters.
      when others => raise;
      -- or whatever, it is usually Constraint_Error that takes all the
      -- work, and any other exceptions are passed back to the caller.
   end; -- nested block.
end Foo;

All that looks like a lot of work, but it isn't usually.  It is just 
that most programmers Ada or otherwise have no idea of what it takes to 
write a subprogram that actually deals with Constraint_Error instead of 
just renaming it or letting it propagate to the caller.

To give just one example, think about an Inverse function for matrices. 
  There are matrices for which the inverse is well defined, there are 
cases where the matix is singular, and there is a third group of cases 
where the matrix is ill conditioned or stiff.  Often it takes a lot more 
CPU cycles to run the cases which can deal with ill-conditioned or stiff 
matrices, so you really do want to try say, simple LU decomposition first.

If you do go to that effort, putting the firewall call in is no big 
deal.  Writing the code so that you can begin over when needed is often 
more work, but in this case you are not inverting the matrix in place 
(unless you pass the matrix with an access parameter).

Now if anyone wants to submit a suggestion to Ada-Comment suggesting 
that there actually be a language defined procedure Firewall that does 
nothing but what its name implies, fine.  Personally I find it easy 
enough to have my own version around and call it.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Robert I. Eachus]

Georg Bauhaus wrote:

> Robert I. Eachus <rieachus@comcast.net> wrote:
> : 
> : And was actually surprised that GNAT didn't give me a warning and do 
> : just that.
> 
> Maybe I just haven't understood, however:
> Compiling: hyman_example.adb (source file time stamp: 2004-03-02 16:28:14)
> 
>     11.      a := 1 / a;
>                     |
>         >>> warning: division by zero
>         >>> warning: "Constraint_Error" will be raised at run time
> 
>  18 lines: No errors, 2 warnings
> 
> (further warnings about C, D, F, G, I, J not being modified
> but not declared constant, if requested.)

Hmmm.  What version, and with which command line parameters? I actually 
used: gnatmake -gnato -f -O3 hyman_example.adb  With GNAT 3.15p for 
Windows/x86.

-- 
                                           Robert I. Eachus

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

Re: In-Out Parameters for functions

[Randy Brukardt]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1078245216.689285@master.nyc.kbcfp.com...
> Jacob Sparre Andersen wrote:
> > But if this really is a serious problem for you, you can handle it by
> > putting each of the five assignments in your sequence of statements
> > within its own begin-exception-end block.
>
> That's not really the point. If I know in micro-detail where a check
> is failing, I could just as easily make it not fail.

Not really. Try writing a multiply routine that detects overflow without
handling the exception.

>  What I expected
> (which will probably earn me another blast from RE for not getting
> the Ada mindset) was that the reason for l-d checks is to prevent the
> kind of errors you find in C, namely undetected erroneous changes that
> trigger problems at some remove from the place where they occurred.
> It seems to me that the Ada rules allow the same sort of thing to
> happen - if I have a handler at a high level for a language-defined
> error, it's possible that any number of objects may have been left in
> an abnormal state when the exception triggered, and I will encounter
> erroneous (and possibly undetected) behavior at some later point.

Handling l-d checks requires great care. It's generally only safe to do so
in a very narrow section of code (like the overflow check mentioned above),
or in a very broad chunk of code (the whole subsystem). Usually, you just
want to log them and either exit or reinitialize everything and start over.
Ada doesn't really support continuation from constraint_error or
storage_error.

                 Randy.

Re: In-Out Parameters for functions

[Georg Bauhaus]

Robert I. Eachus <rieachus@comcast.net> wrote:
: 
: Hmmm.  What version, and with which command line parameters? I actually 
: used: gnatmake -gnato -f -O3 hyman_example.adb  With GNAT 3.15p for 
: Windows/x86.

GCC 3.4 from last year, on GNU/Linux, the div by 0 warning is issued with
no options present (except -gnatv), the could-be-declared-constant warnings
follow after adding -gnatwa.


-- Georg