Parameter evaluation order

Parameter evaluation order

[Mark.Rutten]

I'm using GNAT3.09 on WindowsNT (and also Solaris, but I didn't get
this problem).

I compiled a procedure call similar to the following

  proc(func_one,func_two);

The program relies on func_one being called _before_ func_two. But
at run-time the code above did the opposite! Is this a bug (and if so, has it
been fixed in 3.10)? Or is there something written in the language definition
to justify this behaviour?

Thanks,
Mark Rutten

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading

Re: Parameter evaluation order

[Matthew Heaney]

In article <6g9d2o$tfg$1@nnrp1.dejanews.com>,
Mark.Rutten@dsto.defence.gov.au wrote:

>I'm using GNAT3.09 on WindowsNT (and also Solaris, but I didn't get
>this problem).
>
>I compiled a procedure call similar to the following
>
>  proc(func_one,func_two);
>
>The program relies on func_one being called _before_ func_two. But
>at run-time the code above did the opposite! Is this a bug (and if so, has it
>been fixed in 3.10)? Or is there something written in the language definition
>to justify this behaviour?

No, this is not a bug.  The language does not mandate an order of
evaluation of parameters.

There is a very simple fix:

declare
   Arg1 : constant Arg1Type := Func_One;
   Arg2 : constant Arg2Type := Func_Two;
begin
   proc (Arg1, Arg2);
end;

Re: Parameter evaluation order

[Corey Ashford]

Mark.Rutten@dsto.defence.gov.au wrote in message
<6g9d2o$tfg$1@nnrp1.dejanews.com>...
>
>
>I'm using GNAT3.09 on WindowsNT (and also Solaris, but I didn't get
>this problem).
>
>I compiled a procedure call similar to the following
>
>  proc(func_one,func_two);
>
>The program relies on func_one being called _before_ func_two. But
>at run-time the code above did the opposite! Is this a bug (and if so, has
it
>been fixed in 3.10)? Or is there something written in the language
definition
>to justify this behaviour?
>
>Thanks,
>Mark Rutten


See the Ada RM 6.4 (10)

(10)
    For the execution of a subprogram call, the name or prefix of the call
is evaluated, and each parameter_association is evaluated (see 6.4.1).
    If a default_expression is used, an implicit parameter_association is
assumed for this rule. These evaluations are done in an arbitrary order.
    The subprogram_body is then executed. Finally, if the subprogram
completes normally, then after it is left, any necessary assigning back of
    formal to actual parameters occurs (see 6.4.1).

Re: Parameter evaluation order

[William D. Ghrist]

Mark.Rutten@dsto.defence.gov.au wrote:
> 
> I'm using GNAT3.09 on WindowsNT (and also Solaris, but I didn't get
> this problem).
> 
> I compiled a procedure call similar to the following
> 
>   proc(func_one,func_two);
> 
> The program relies on func_one being called _before_ func_two. But
> at run-time the code above did the opposite! Is this a bug (and if so, has it
> been fixed in 3.10)? Or is there something written in the language definition
> to justify this behaviour?
> 
> Thanks,
> Mark Rutten
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/   Now offering spam-free web-based newsreading

Yes, it is a bug in your program.  The order of execution of parameters
is not defined (this is true in other languages besides Ada, as well). 
This is one of the reasons that it is considered poor practice to write
functions with side effects.  If you must use functions with side
effects that result in situations like your example, then the valid way
to proceed is to invoke the functions first, storing their return values
in variables, then to call the procedure with the variables as
parameters.

Regards,
Bill Ghrist

Re: Parameter evaluation order

[Don Harrison]

Mark.Rutten wrote:

:I compiled a procedure call similar to the following
:
:  proc(func_one,func_two);
:
:The program relies on func_one being called _before_ func_two..

IMO, the problem is that Func_One generates a side-effect on which Func_Two
depends. Remove the side-effect and the problem will disappear!

I think what you really want is:

  do_side_effect;
  proc (func_one, func_two);.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison        doELIDEnh@syd.csa.com.au

Re: Parameter evaluation order

[Glenden Lee]

Mark.Rutten@dsto.defence.gov.au wrote:


: I'm using GNAT3.09 on WindowsNT (and also Solaris, but I didn't get
: this problem).

: I compiled a procedure call similar to the following

:   proc(func_one,func_two);

: The program relies on func_one being called _before_ func_two. But
: at run-time the code above did the opposite! Is this a bug (and if so, has it
: been fixed in 3.10)? Or is there something written in the language definition
: to justify this behaviour?

Your compiler is probably optimizing it somehow.  Why don't you just break
it down into several lines?  It'd be easier to maintain for the next person
that looks at your code also.

G.
-- 
Glenden Lee
Array Systems Computing
1120 Finch Avenue West
North York, Ontario

Re: Parameter evaluation order

[Robert Dewar]

Glenden said

<<Your compiler is probably optimizing it somehow.  Why don't you just break
it down into several lines?  It'd be easier to maintain for the next person
that looks at your code also.
>>

This is misleading. This has nothing to do with optimization, The order
of parameter evaluation is non-deterministic, the program worked exactly
as it should, it was just that the programmer had some incorrect expectation
based on a misunderstanding of Ada semantics.

Re: Parameter evaluation order

[Peter Amey]

I have been trying to resist the temptation but...

Robert A Duff wrote:
> 
> In article <dewar.892128071@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
> >This is misleading. This has nothing to do with optimization, The order
> >of parameter evaluation is non-deterministic, the program worked exactly
> >as it should, it was just that the programmer had some incorrect expectation
> >based on a misunderstanding of Ada semantics.
> [snip]
> 
> I'm not even convinced the tradeoff is worthwhile.  That is, perhaps it
> *is* a stupid rule, despite the fact that it might make some programs
> run faster.  I don't like nondeterministic semantics.
> 

...if you really don't like non-deterministic semantics you need to program in
SPARK.  The originally-posted code would not malfunction if it were in SPARK
because the function calls used as actual parameters would not have side-effects
and so the evaluation order would not matter.  SPARK also provides complete
protection against erroneous behaviour arising from parameter passing mechanisms, 
elaboration order etc. Incidently, you don't need to use functions to get the effect
described, consider:

procedure Init2(X, Y : out integer) is
begin
  X := 0;
  Y := 1;
end Init2;

What is the meaning of Init2(A, A);  ?   

regards Peter

---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/
 --------------------------------------------------------------------------

Re: Parameter evaluation order

[Tucker Taft]

Robert A Duff (robertduff@world.std.com) wrote:

: ...
: I'm not even convinced the tradeoff is worthwhile.  That is, perhaps it
: *is* a stupid rule, despite the fact that it might make some programs
: run faster.  I don't like nondeterministic semantics.

I do. ;-).

It is interesting that Djikstra in his classic book
"A Discipline of Programming" chose to write it all using
non-deterministic control flow constructs.  This is in spite
of the fact that he is very interested in proving programs
correct.  Implicit in this is that proving properties of programs
is not necessarily harder in the presence of non-deterministic
semantics.  In some cases, non-determinism actually simplifies 
the program proving rules.  Furthermore, multitasking programs
are inevitably non-deterministic, and as we move to hardware
where speed is achieved by increasing the number of processors
rather than just the speed of individual processors, 
non-deterministic semantics are even more important.

As an example of simplification, the rules for real model intervals
in Ada are not trivial, but they are much simpler to work with
than trying to reflect the exact IEEE rounding-to-nearest-even
rules in attempts to prove programs.  Of course the 
rounding-to-nearest-even has nice statistical properties,
but clearly when you start relying on statistical properties,
you are not talking determinism!

I think the attempts to make Java's semantics deterministic
were misguided.  My understanding is that they have finally
relented with respect to floating point calculations, and will
allow extended-precision intermediates during evaluation of
floating point expressions.  Given that multi-tasking is
a big part of Java, and they didn't even incorporate a clean
race-free state-based task signaling mechanism like entry barriers, 
but instead use the notoriously race-prone wait/notify approach,
specifying order of evaluation of parameters seems to be 
missing the forest for the trees.

: - Bob
: -- 
: Change robert to bob to get my real email address.  Sorry.

Stepping off the soapbox...

-Tuck

Re: Parameter evaluation order

[Simon Wright]

matthew_heaney@acm.org (Matthew Heaney) writes:

> No, this is not a bug.  The language does not mandate an order of
> evaluation of parameters.
> 
> There is a very simple fix:
> 
> declare
>    Arg1 : constant Arg1Type := Func_One;
>    Arg2 : constant Arg2Type := Func_Two;
> begin
>    proc (Arg1, Arg2);
> end;

I was wondering if, because the order need arises from [invisible?]
side-effects, a compiler might be allowed to reorder the declarations;
but 3.11(7) says

The elaboration of a declarative_part consists of the elaboration of
the declarative_items, if any, in the order in which they are given in
the declarative_part.

Re: Parameter evaluation order

[Simon Wright]

matthew_heaney@acm.org (Matthew Heaney) writes:

> In article <x7vemz7xncq.fsf@pogner.demon.co.uk>, Simon Wright
> <simon@pogner.demon.co.uk> wrote:
> 
> >> declare
> >>    Arg1 : constant Arg1Type := Func_One;
> >>    Arg2 : constant Arg2Type := Func_Two;
> >> begin
> >>    proc (Arg1, Arg2);
> >> end;
> >
> >I was wondering if, because the order need arises from [invisible?]
> >side-effects, a compiler might be allowed to reorder the declarations;
> >but 3.11(7) says
> >
> >The elaboration of a declarative_part consists of the elaboration of
> >the declarative_items, if any, in the order in which they are given in
> >the declarative_part.
> 
> The term is "linear elaboration" of declarations.  You need this so you can
> use the value of an object previously declared.  It's the same as the let*
> expression in Lisp (compare let).

Yeah, but a compiler *might* have been given permission to re-order
elaborations if it could tell that there would be no difference ..

Re: Parameter evaluation order

[Matthew Heaney]

In article <x7vemz7xncq.fsf@pogner.demon.co.uk>, Simon Wright
<simon@pogner.demon.co.uk> wrote:

>> declare
>>    Arg1 : constant Arg1Type := Func_One;
>>    Arg2 : constant Arg2Type := Func_Two;
>> begin
>>    proc (Arg1, Arg2);
>> end;
>
>I was wondering if, because the order need arises from [invisible?]
>side-effects, a compiler might be allowed to reorder the declarations;
>but 3.11(7) says
>
>The elaboration of a declarative_part consists of the elaboration of
>the declarative_items, if any, in the order in which they are given in
>the declarative_part.

The term is "linear elaboration" of declarations.  You need this so you can
use the value of an object previously declared.  It's the same as the let*
expression in Lisp (compare let).

Re: Parameter evaluation order

[Robert Dewar]

Simon says

<<Yeah, but a compiler *might* have been given permission to re-order
elaborations if it could tell that there would be no difference ..
>>


There is never any question of giving compilers permission to do things
to the code that make no difference in the behavior. There is no possible
way of "stopping" the compiler from doing X if X has no effect on the
semantic behavior of the program, because the concept of stopping the
compiler from doing X has no meaning in such a case.

Re: Parameter evaluation order

[Nick Roberts]

As a quick addendum: the term 'non-deterministic' has been bandied about in
this thread, when the (longer!) term 'sequentially non-deterministic' might
have been clearer. Alternatively, the term 'unsequenced' could be used
(although it is usually used only in the context of parallel processing, I
don't see why not).

None of the constructs being discussed are actually non-deterministic (in
the conventional sense): this is a very esoteric branch of computing indeed!
(Related to natural learning systems, for the curious.) (Oh, and lottery
machines!)

--
Nick Roberts, Croydon, UK
Nick.Roberts@dial.pipex.com

Re: Parameter evaluation order

[Robert Dewar]

Nick said

<<None of the constructs being discussed are actually non-deterministic (in
the conventional sense): this is a very esoteric branch of computing indeed!
(Related to natural learning systems, for the curious.) (Oh, and lottery
machines!)
>>


That is completely false. The conventional sense of non-deterministic in
the programming language field is that the effect of a given construct
is a non-deterministic selection from a set of possible outcomes.

Sometimes non-determinism has been used in conjunction with backtracking
semantics, where the model is that the "right" selection is made. Lambert
Meertens suggested some years ago the term "angelic non-determinism" for
this case.

Note that arbitrary selection has NOTHING AT ALL to do with random
selection (I suspect that may be part of Nick's confusion, given that
he mentions lottery machines, where randomness is what is wanted).

So saying that, for example the select statement in Ada 83, makes an
arbitrary selection of which branch to choose among several open branches
does not require or even vaguely imply some kind of "fair" random selection.
(I have been amazed at how many people have been confused on this particular
point, including some supposed experts in Ada :-)

The terms that Nick suggests, e.g. sequential non-determinism, are in my
opinion non-standard and confusing.

As you read the above, you will see that I use non-deterministic selection
and arbitrary selection from a set as synonyms. This is intentional, and
this is the conventional usage.

(related reading: the definition of SETL and its arb operator)