madmats@elma.epfl.ch (Mats Weber) (02/21/89)
Question: is the following program erroneous ?
procedure Is_This_Program_Erroneous is
type Vector is array (1..5) of Float;
A_Vector : Vector := (0.35, 0.67, 1.8, 2.0, 7.7);
procedure Add (V : in Vector; W : in out Vector) is
begin
for I in 1..5 loop
W(I) := V(I) + W(I);
end loop;
end Add;
begin
Add(A_Vector, A_Vector);
end Is_This_Program_Erroneous;
The effect of this program does not depend on the parameter passing
mechanism (copy or reference). Note that a similar example is said
to be correct in "Rationale for the design of the Ada language".
According to LRM 6.2(7), the program is correct because its effect does
not depend on the parameter passing mechanism.
But according to LRM 6.2(13) - which is a note and as such is not part of
the standard - the program is erroneous because there are multiple access
paths to A_Vector during the call Add(A_Vector, A_Vector);, and therefore
V is undefined after the assignment W(1) := V(1) + W(1);
Mats Weber
Swiss Federal Institute of Technology
EPFL DI LITh
1015 Lausanne
Switzerland
e-mail : madmats@elma.epfl.chharrison@software.org (Tim Harrison) (02/22/89)
Mats Weber asks: > Question: is the following program erroneous ? > > procedure Is_This_Program_Erroneous is > > type Vector is array (1..5) of Float; > > A_Vector : Vector := (0.35, 0.67, 1.8, 2.0, 7.7); > > procedure Add (V : in Vector; W : in out Vector) is > begin > for I in 1..5 loop > W(I) := V(I) + W(I); > end loop; > end Add; > > begin > Add(A_Vector, A_Vector); > end Is_This_Program_Erroneous; > But according to LRM 6.2(13) - which is a note and as such is not part of > the standard - the program is erroneous because there are multiple access > paths to A_Vector during the call Add(A_Vector, A_Vector);, and therefore > V is undefined after the assignment W(1) := V(1) + W(1); The program in question is not erroneous. LRM 6.2(13) says that "the value of the formal is undefined after updating the actual other than by updating formal." In the example program the actual is A_Vector and the formals are V and W. The example program is only updating the formal (W) not the actual (A_Vector). If the program were procedure Is_This_Program_Erroneous is type Vector is array (1..5) of Float; A_Vector : Vector := (0.35, 0.67, 1.8, 2.0, 7.7); procedure (V : in Vector) is begin for I in 1..5 loop A_Vector(I) := A_Vector(I) + V(I); end loop; end Add; begin Add(A_Vector); end Is_This_Program_Erroneous; the program would be erroneous (according to LRM 6.2(13)), because the actual (A_Vector) would be updated other than through the formal (V). -- Tim Harrison Software Productivity Consortium Phone: (703) 742-7113 SPC Building CSnet: harrison@software.org 2214 Rock Hill Road ARPAnet: harrison@ajpo.sei.cmu.edu Herndon, Virginia 22070
madmats@elma.epfl.ch (Mats Weber) (02/23/89)
Tim Harrison <harrison@software.org> writes: >The program in question is not erroneous. LRM 6.2(13) says that "the value >of the formal is undefined after updating the actual other than by updating >formal." In the example program the actual is A_Vector and the formals are >V and W. The example program is only updating the formal (W) not the actual >(A_Vector).... My example was: > procedure Is_This_Program_Erroneous is > > type Vector is array (1..5) of Float; > > A_Vector : Vector := (0.35, 0.67, 1.8, 2.0, 7.7); > > procedure Add (V : in Vector; W : in out Vector) is > begin > for I in 1..5 loop > W(I) := V(I) + W(I); > end loop; > end Add; > > begin > Add(A_Vector, A_Vector); > end Is_This_Program_Erroneous; There are two points: 1) This program is not erroueous according to the LRM because its effect does not depend on whether V and W are passed by reference or by copy. 6.2(13) is a NOTE and according to LRM 1.2(7), notes are not part of the standard. The problem with 6.2(13) is that it is not a consequence of other rules. 2) 6.2(13) applies here because if V and W are passed by reference, the actual A_Vector is updated by the assignment W(1) := V(1) + W(1); other than by updating the formal V, which makes V(2..5) undefined according to 6.2(13). (See 6.2(7): "... by arranging that every use of the formal parameter be treated as a use of the associated actual parameter..."). Mats Weber Swiss Federal Institute of Technology EPFL DI LITh 1015 Lausanne Switzerland e-mail : madmats@elma.epfl.ch