* Re: Parameter evaluation order
1998-04-05 0:00 Parameter evaluation order Mark.Rutten
@ 1998-04-05 0:00 ` Matthew Heaney
1998-04-07 0:00 ` Don Harrison
1998-04-09 0:00 ` Simon Wright
1998-04-06 0:00 ` William D. Ghrist
` (2 subsequent siblings)
3 siblings, 2 replies; 15+ messages in thread
From: Matthew Heaney @ 1998-04-05 0:00 UTC (permalink / raw)
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;
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-05 0:00 ` Matthew Heaney
@ 1998-04-07 0:00 ` Don Harrison
1998-04-09 0:00 ` Simon Wright
1 sibling, 0 replies; 15+ messages in thread
From: Don Harrison @ 1998-04-07 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-05 0:00 ` Matthew Heaney
1998-04-07 0:00 ` Don Harrison
@ 1998-04-09 0:00 ` Simon Wright
1998-04-10 0:00 ` Matthew Heaney
1 sibling, 1 reply; 15+ messages in thread
From: Simon Wright @ 1998-04-09 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-09 0:00 ` Simon Wright
@ 1998-04-10 0:00 ` Matthew Heaney
1998-04-10 0:00 ` Simon Wright
0 siblings, 1 reply; 15+ messages in thread
From: Matthew Heaney @ 1998-04-10 0:00 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-10 0:00 ` Matthew Heaney
@ 1998-04-10 0:00 ` Simon Wright
1998-04-11 0:00 ` Robert Dewar
0 siblings, 1 reply; 15+ messages in thread
From: Simon Wright @ 1998-04-10 0:00 UTC (permalink / raw)
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 ..
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-10 0:00 ` Simon Wright
@ 1998-04-11 0:00 ` Robert Dewar
0 siblings, 0 replies; 15+ messages in thread
From: Robert Dewar @ 1998-04-11 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-05 0:00 Parameter evaluation order Mark.Rutten
1998-04-05 0:00 ` Matthew Heaney
@ 1998-04-06 0:00 ` William D. Ghrist
1998-04-06 0:00 ` Corey Ashford
1998-04-08 0:00 ` Glenden Lee
3 siblings, 0 replies; 15+ messages in thread
From: William D. Ghrist @ 1998-04-06 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-05 0:00 Parameter evaluation order Mark.Rutten
1998-04-05 0:00 ` Matthew Heaney
1998-04-06 0:00 ` William D. Ghrist
@ 1998-04-06 0:00 ` Corey Ashford
1998-04-08 0:00 ` Glenden Lee
3 siblings, 0 replies; 15+ messages in thread
From: Corey Ashford @ 1998-04-06 0:00 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-05 0:00 Parameter evaluation order Mark.Rutten
` (2 preceding siblings ...)
1998-04-06 0:00 ` Corey Ashford
@ 1998-04-08 0:00 ` Glenden Lee
1998-04-09 0:00 ` Robert Dewar
3 siblings, 1 reply; 15+ messages in thread
From: Glenden Lee @ 1998-04-08 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Parameter evaluation order
1998-04-08 0:00 ` Glenden Lee
@ 1998-04-09 0:00 ` Robert Dewar
[not found] ` <Er5Ir9.5Ip@world.std.com>
0 siblings, 1 reply; 15+ messages in thread
From: Robert Dewar @ 1998-04-09 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 15+ messages in thread