Programming CS2130 Language Concepts and Paradigms
Unit 5 Function and Procedure Abstractions Functions A function definition establishes name for a program entity which, when called, yields a value (of a specific type) which usually depends on one or more argument values. Functions fulfil the same general rle as expressions, but hide the details of the calculation of a value behind the name of the function. There is a separation between the function value and the details of the way in which the value is calculated. Functions thus provide abstraction over expressions and, if given meaningful names, can improve program clarity, for example instead of:
IF (ch >= 'A' AND Ch <= 'Z') OR (ch >= 'a' AND Ch <= 'z') THEN ...
we have
IF IsLetter(Ch) THEN ...
where
FUNCTION IsLetter(C : Character) RETURN Boolean IS BEGIN RETURN (C >= 'A' AND C <= 'Z') OR (C >= 'a' AND C <= 'z'); END IsLetter;
Side Effects Functions can have local variables and employ commands, but provided the latter have no effect on program state outside the function, the correspondence between expressions and functions is maintained and we say the function is free of side-effects. However if a function, as well as returning a value, modifies program state (outside the function body) either by altering a (non-local) program variable or by performing I/O operations the function is said to have side-effects. Side-effect functions thus confuse two notions: namely expression evaluation to produce a value and commands to modify program state. In Ada functions are not allowed to have OUT or IN OUT mode parameters which prevents one important mechanism for producing side effects. However other languages are more liberal: in Pascal it is possible to define functions with VAR parameters and in C++ functions may have reference parameters. Similarly because Java uses reference semantics for objects, a function can alter the state of an object passed to it as a paramter. All such functions can modify program state by altering variables passed as actual parameters. Functions with side effect can lead to code which is hard to understand or even to undefined program behaviour (cf. operators with side-effects as discussed in a previous lecture). For example in C++
int funny(int& x) { x = x+1; return 2*x; } a[i]= funny(i); // does this set a[2] or a[1] to 4 ?
Note a similar effect can be achieved in Ada (and many other languages) by allowing a function to modify a non-local variable:
I : Integer := 1; A : ARRAY(1 .. 10) OF Integer; FUNCTION RumDo RETURN Integer IS BEGIN I := I+1; RETURN 2*I; END RumDo; ...... A(I) := RumDo; -- does this set A(2) or A(1) to 4 ?
A Barnes, 2005
1
CS2130/Unit 5
The language occam2 is more strict then Ada: a function cannot have OUT or IN OUT mode parameters and moreover a function body is not allowed to change non-local variables and thus side-eefects are avoided. Functions with I/O side-effects can similarly give rise to obscure code and possibly undefined program behaviour. Thus it is best (if possible) to avoid writing functions with side effects even if the language permits it. Procedures A procedure declaration names a group of commands which are obeyed when the procedure is called. There is a separation between what a procedure does and how it does it; thus procedures provide abstraction over commands. Procedures return no value; the entire purpose of calling a procedure is to cause side effects. In the C family of languages there are no procedures as such, but functions returning void fulfil the same role as procedures. Parameters Without parameters procedures1 support abstraction only via naming a group of commands. Parameters make the abstraction more powerful through generalisation allowing the procedure to perform differing tasks depending on the parameters supplied in the procedure call. For example instead of a procedure sorting a specific array we can write a procedure to sort any array with a parameter specifying the particular array to be sorted when the procedure is called. An argument is a value which is passed to a subprogram abstraction. An identifier used within a subprogram (procedure or function) abstraction to denote an argument is called a formal parameter. A literal, variable or expression which, in a subprogram call, is evaluated to yield an argument is called an actual parameter. When a subprogram is called each formal parameter becomes associated with an actual parameter. Different languages provide differing parameter mechanisms for associating actual and formal parameters. Value Parameters or Copy-in Parameters On entry to a subprogram storage is allocated by a formal parameter X (say), the corresponding actual parameter (which may be any expression) is evaluated and the resulting argument (value) copied to X. We say the parameter is passed by value. Thereafter the parameter behaves just like a local variable: its value may be inspected and updated. However its updating has no effect on the actual parameter or indeed on any non-local entities. In Pascal, Modula-2 and C + + parameters are by default value parameters. In C all parameters (except array parameters) are value parameters. Actual Parameter Value Value copied on subprogram call Reference Value Value Cell Result Parameters or Copy-out Parameters On entry to a subprogram storage is allocated by a formal parameter X (say), but its initial value is undefined. On exit from the subprogram the value of X is copied to the corresponding actual parameter which must therefore have a left-value (i.e. it must be a variable, array element or other
1
Formal Parameter X
Similar remarks apply to function parameters.
2 CS2130/Unit 5
A Barnes, 2005
entity denoting an updateable storage location). In Ada OUT parameters of non-composite types (that is primitive types and pointer types) are result parameters. Actual Parameter Name Reference Value Cell Value Value copied as subprogram returns Reference Value Value Cell Value-Result Parameters or Copy-in/Copy-out Parameters The above two mechanisms are combined: on entry to a subprogram storage is allocated by a formal parameter X (say), the corresponding actual parameter is evaluated and the value copied to X.. On exit from the subprogram the final value of X is copied to the corresponding actual parameter which must therefore have a left-value. In Ada IN OUT parameters of non-composite types are value-result parameters. Actual Parameter Name Reference Value Cell Value Value copied as subprogram returns Value Value Cell Constant Parameters In this case the formal parameter X (say) is bound directly to the value of the corresponding actual parameter as the subprogram is called and the binding remains in effect until the subprogram returns. Hence the value of X remains constant throughout each individual subprogram call. In Ada IN parameters have the semantics of constant parameters; however for non-composite types the actual implementation method is a copy-in mechanism to a nonupdateable storage location X rather than a direct value binding. Variable Parameters or Reference Parameters In this case the argument is a reference to the storage location associated with the actual parameter; the formal parameter X (say) is bound to the storage associated with the actual parameter which must have a left-value. Thus for the duration of the subprogram call, X and the actual parameter refer to the same storage location and any updating of X is therefore an updating of the associated actual parameter. In effect the address of the actual parameter is passed to the subprogram which can then update the actual parameter directly. In Pascal and Modula-2 VAR parameters are reference parameters as are reference parameters in C++. In C++ reference parameters are denoted by appending an ampersand character to the
Formal Parameter X
Formal Parameter X
Value copied on subprogram call
Reference
A Barnes, 2005
3
CS2130/Unit 5
parameter type in the function declaration. In C and C++ array parameters are in effect reference parameters. Actual Parameter Name Reference Value Cell Value
Formal Parameter X Reference
Although the Ada standard specifies that parameters of a non-composite types (primitive types such as Integer, Float etc. and pointer types) are passed by copying, it does not define the parameter passing mechanism for composite types such as arrays and records. The implementor of an Ada compiler may choose to use a copying or a reference mechanism (or a mixture of the two). For efficiency reasons modern implementations tend to use parameter passing by reference. For tagged record types (used in OO Ada programming) the standard specifies that the reference mechanism must be used. Note that whether a reference or copy-in mechanism used for IN mode parameters, constant semantics are enforced by the compiler which prevents any assignments to the parameter within the subprogram body. Thus the situation in Ada can be summarised in the following table Parameter Mode
IN OUT IN OUT
non-composite type
composite type
tagged type reference (constant semantics) reference reference
value value or reference (constant semantics) (constant semantics) result result or reference value-result value-result or reference
In Java, values of a primitive type are passed to methods by value and so cannot be updated by a method. Actual Parameter Name Reference Reference Cell
Ref. to actual data structure
Value Storage for actual data structure
Formal Parameter X Reference
Reference copied on method call
Ref. to actual data structure
Reference Cell In Java in a certain sense, objects (including arrays, strings and string buffers) are also passed to methods by value, but because of the reference semantics, the object can be updated by the method and so the effect is almost as the same as if they were passed by reference. To see this consider the diagram on the previous page; when a method is called storage is allocated for the formal parameter and the FP name bound to this storage location and then the address in the
A Barnes, 2005
4
CS2130/Unit 5
reference cell of the AP is copied to the reference cell of the FP and so these both refer to the same underlying object for the duration of the method call. Thus a data field (data member) f of the object and elements of an array passed as an AP can be altered by the function by assignments of the form
X.f = <some-value>;
Note however that the since the reference is copied, an assignment inside the function of the form
X = new <object constructor>;
though legal, does not change the object passed as actual paramter. Example The difference between value and VAR (reference) parameters is illustrated below: Pascal
PROCEDURE swap(x, y : Integer); VAR tmp : Integer; BEGIN tmp := x; x := y; y := tmp; END; ....... swap(a, b);
C++
void swap(int x, y) { int tmp; tmp = x; x = y; y = tmp; } ....... swap(a, b);
In the above code value parameters are used so the procedure swap copies the contents of variables a and b to x and y and then swaps the copied values. Hence it has no effect on the values of the variables a and b themselves. Pascal
PROCEDURE swap(VAR x, y : Integer); VAR tmp : Integer; BEGIN tmp := x; x := y; y := tmp; END; ....... swap(a, b);
C++
void swap(int& x, y) { int tmp; tmp = x; x = y; y = tmp; } ....... swap(a, b);
Here reference parameters are used and so the in the call parameters x and y are bound to the same locations as variables a and b respectively. Hence any change to the parameter x updates the variable a and similarly for y and b. In Ada the analogue of the above code using IN parameters would be illegal as such parameters have constant parameter semantics. To work correctly the procedure would need to use IN OUT parameters: the procedure swap copies the contents of variables a and b to x and y and then swaps the copied values, but as it returns the contents of parameters x and y is copied back to a and b respectively. Hence the effect of the procedure call is to swap the values of the variables a and b themselves. The advantage of reference parameters is efficiency as the copying of values is avoided; this is particularly important for values of large composite types. The main disadvantage of reference parameters is the danger of aliasing which will be considered in the next section. Aliasing It is also possible to have two or more names bound to the same entity. In this case we say that the entity is aliased. We have seen an example of this with arrays in Java in Unit 3 where, because of the reference semantics, after the declarations:
A Barnes, 2005
5
CS2130/Unit 5
int[] a = new int[100]; int[] b = a; a and b refer to the same underlying array.
If a variable in a language using value semantics is aliased, the situation could be visualised as Name2 Reference Value Cell Value Name1 Reference
Note that this exactly the situation that occurs during a subprogram call when parameter passing by reference is used; the formal and actual parameters are aliases for the storage same location for the duration of the subprogram call. This aliasing itself does not normally cause confusion as we would normally only use the formal parameter name to refer to the storage location in the subprogram body. However consider the following situation (known as parameter-induced aliasing) when the same actual parameter is passed by reference2 twice as in the C++ procedure swap:
void swap(int& x, y) { x = x + y; y = x - y; // y now holds the original value of x x = x - y; // x now holds the original value of y } ....... swap(a, b); // works OK swap(a, a); // sets a to zero
The problem in the second call is that the formal parameters x and y are both aliases for the AP a and the 'clever' trick of swapping without the need for a temporary variable fails in this case. Note that the analogue of the above code works correctly in Ada for values of non-composite types as IN OUT parameters are guaranteed to use value-result (copy-in/copy-out) semantics:
PROCEDURE Swap(X, Y : IN OUT Integer) IS BEGIN X := X + Y; Y := X - Y; -- Y now holds the original value of X X := X - Y; -- X now holds the original value of Y END Swap; ....... Swap(A, B); -- works OK Swap(A, A); -- works OK
However analogous code for composite types is not guaranteed to work in the presence of aliasing (such as the array type Vector of Unit 2). It would work correctly if value-result parameter mechanism is used but not if the reference parameter mechanism is used.
TYPE Vector IS ARRAY(Positive RANGE <>) OF Float; SUBTYPE Vector3 IS Vector(1 .. 3); A, B : Vector3;
2
Similar problems arise in Java for parameters of composite type because of the reference semantics.
A Barnes, 2005 6 CS2130/Unit 5
PROCEDURE Swap(X, Y : IN OUT Vector) IS BEGIN X := X + Y; Y := X - Y; -- Y now holds the original value of X X := X - Y; -- X now holds the original value of Y END Swap; ....... Swap(A, B); -- works OK Swap(A, A); -- fails if arrays are passed by reference
Note that recent versions of the Gnat Ada compiler use parameter passing by reference for all composite types. Hence the above code for Swap would not work correctly in the presence of aliasing. However versions of Gnat prior to 3.09 used a call by value-result for IN OUT parameters of small composite data types (of size less than 32 bytes), but call by reference for larger data structures. Thus, even in the presence of aliasing, the above code for Swap would have worked as intended for the subtype Vector3, but not for larger subtypes such as Vector(1 .. 10). All very confusing! The above Swap procedure is somewhat artificial, but parameter-induced aliasing can occur in more practical situations. Consider the following implementation of a set data structure:
PACKAGE Set_ADT IS TYPE Elem IS ...; -- any old Ada type or subtype TYPE Set IS LIMITED PRIVATE; PROCEDURE Intersection(S1, S2 : IN Set; Result : OUT Set); ......... -- other exported set operations Union, Equal etc. PRIVATE MaxSize : CONSTANT Positive := ...; TYPE ElemArray IS ARRAY(1 .. MaxSize) OF Elem; TYPE Set IS RECORD Size : Natural RANGE 0 .. MaxSize; Elems : ElemArray; END RECORD; END Set_ADT; PACKAGE BODY Set_ADT IS PROCEDURE Intersection(S1, S2 : IN Set; Res : OUT Set) IS BEGIN Res.Size := 0; FOR I IN 1 .. S1.Size LOOP FOR J IN 1 .. S2.Size LOOP IF S1.Elems(I) = S2.Elems(J) THEN -- if element is in both S1 & S2, add it to Res set Res.Size := Res.Size + 1; Res.Elems(Res.Size) := S1.Elems(I); EXIT; -- exit FOR J loop END IF; END LOOP; END LOOP; END Intersection; -- implementations of other set operations. END Set_ADT;
If the Ada implementation uses call by reference for the record type Set, Intersection does not behave correctly due to parameter-induced aliasing in calls such as
A, B : Set; ............. Intersection(S1 => A, S2 => B, Res => B);
A Barnes, 2005
7
CS2130/Unit 5
The first step in the procedure sets Res.Size to zero and because of the aliasing of Res and S2 this sets S2.Size to zero and so the body of the FOR J loop is never executed and the procedure always terminates with an empty Res set. The correct way to code Intersection is to use a local variable Tmp (say) to build up the result and only assign to the OUT parameter Res just before the procedure returns:
PROCEDURE Intersection(S1, S2 : IN Set; Res : OUT Set) IS Tmp : Set; BEGIN Tmp.Size := 0; FOR I IN 1 .. S1.Size LOOP FOR J IN 1 .. S2.Size LOOP IF S1.Elems(I) = S2.Elems(J) THEN -- if element is in both S1 & S2, add it to Tmp set Tmp.Size := Tmp.Size + 1; Tmp.Elems(Tmp.Size) := S1.Elems(I); EXIT; -- exit FOR J loop END IF; END LOOP; END LOOP; Res := Tmp; END Intersection;
This avoids the problems with aliasing as assignments to Tmp do not, of course, affect S2 (nor S1) and the final assignment to Res can do no harm as it is the last command in the procedure. In Ada83 the value of an OUT parameter could not be used in a procedure body; OUT parameters could only be appear on the left-hand side of assignments (or be passed as OUT mode parameters to other procedures). Thus an Ada83 programmer would be forced by the language to introduce a temporary local variable Tmp when coding the Intersection procedure. However this restriction on OUT parameters was removed in Ada95 as it meant that an Ada83 programmer often needed to introduce an extra local variable (even when there was no possibility of aliasing) and then assign the value of the local variable to the OUT parameter immediately before the procedure returned. For example,: Ada95
PROCEDURE AddUp(V : IN Vector; T : OUT Float) IS BEGIN T := 0.0; FOR I IN V'Range LOOP T := T + V(I); END LOOP; END AddUp;
Ada83
PROCEDURE AddUp(V : IN Vector; T : OUT Float) IS Temp : Float := 0; BEGIN FOR I IN V'Range LOOP Temp := Temp + V(I); END LOOP; T := Temp; -- set OUT parameter END AddUp;
Note that parameter-induced aliasing is not a problem if it only involves IN mode parameters
Intersection(S1 => A, S2 => A, Res => B);
because the value of such parameters cannot be altered in the subprogram body. If possible one should code procedures with several IN mode parameters and one OUT mode parameter, as functions (or operators) as this will avoid accidental problems with aliasing.
A Barnes, 2005 8 CS2130/Unit 5
However, coding the procedure Intersection above as a function is not particularly useful as the type Set is LIMITED PRIVATE and thus the function return value cannot be assigned to a variable. Such a return value can only be passed to other subprograms as an I N mode parameter. If an implementation uses call by reference for parameters of a certain type, note that in Ada95 (but not in Ada83) OUT parameters of this type behave exactly like IN OUT parameters3 . However as a matter of good programming style4 IN OUT mode should be used when a value is being passed into a procedure, modified and then passed out of the procedure; if no value is being passed in via a parameter, then OUT mode should be used. Normal-Order and Eager Evaluation In Ada, and indeed most imperative languages, actual parameters are all evaluated at the start of a subprogram call, before execution of the subprogram body begins. This is known as eager evaluation. Some functional languages (Miranda and Haskell, but NOT Lisp) use normal order evaluation. In this the actual parameter is not immediately evaluated at the time of a function call, but in effect the actual parameter is substituted for each occurrence of the formal parameter in the function body. The actual parameter is not actually evaluated until control reaches a step that references the corresponding formal parameter. If control never reaches such a step, the actual parameter is never evaluated. Parameters which use a normal-order evaluation mechanism are often referred to as name parameters and are said to be passed by name. A function is said...