# Procedural parameter

### From Seo Wiki - Search Engine Optimization and Programming Languages

In computing, a **procedural parameter** is a parameter of a procedure that is itself a procedure.

This concept is an extremely powerful and versatile programming tool, because it allows programmers to modify certain steps of a library procedure in arbitrarily complicated ways, without having to understand or modify the code of that procedure.

This tool is particularly effective and convenient in languages that support local function definitions, such as Pascal and the modern GNU dialect of C. It is even more so when function closures are available. The same functionality (and more) is provided by objects in object oriented programming languages, but at a significantly higher cost.

## Contents |

## Basic concept

In most languages that provide this feature, a procedural parameter *f* of a subroutine *P* can be called inside the body of *P* as if it were an ordinary procedure:

procedureP(f):returnf(6,3) *f(2,1)

When calling the subroutine *P*, one must give it one argument, that must be some previously defined function compatible with the way *P* uses its parameter *f*. For example, if we define

procedureplus(x,y):returnx+y

then we may call *P* (*plus*), and the result will be *plus*(6,3) * *plus*(2,1) = (6 + 3)*(2 + 1) = 27. On the other hand, if we define

procedurequot(u,v):returnu/v

then the call *P* (*quot*) will return *quot*(6,3)**quot*(2,1) = (6/3)*(2/1) = 4. Finally, if we define

procedureevil(z)returnz + 100

then the call *P* (*evil*) will not make much sense, and may be flagged as an error.

### Syntactic details

Some programming languages that have this feature may allow or require a complete type declaration for each procedural parameter *f*, including the number and type of its arguments, and the type of its result, if any. For example, in the C programming language the example above could be written as

int P ( int f (int a, int b) ) { return f(6,3) * f(2,1); }

In principle, the actual function *actf* that is passed as argument when *P* is called must be type-compatible with the declared type of the procedure parameter *f*. This usually means that *actf* and *f* must return the same type of result, must have the same number of arguments, and corresponding arguments must have the same type. The names of the arguments need not be the same, however, as shown by the *plus* and *quot* examples above. However, some programming languages may me more restrictive or more liberal in this regard.

### Scoping

In languages that allow procedural parameters, the scoping rules are usually defined in such a way that procedural parameters are executed in their native scope. More precisely, suppose that the function *actf* is passed as argument to *P*, as its procedural parameter *f*; and *f* is then called from inside the body of *P*. While *actf* is being executed, it sees the environment of its definition.Template:Example needed

The implementation of these scoping rules is not trivial. By the time that *actf* is finally executed, the activation records where its environment variables live may be arbitrarily deep in the stack. This is the so-called downwards funarg problem.

## Example: Generic insertion sort

The concept of procedural parameter is best explained by examples. A typical application is the following generic implementation of the insertion sort algorithm, that takes two integer parameters *a*,*b* and two procedural parameters *prec*, *swap*:

procedureisort(a,b,prec,swap):integeri,j;i<math>\gets</math>a;whilei<math>\leq</math>bdoj<math>\gets</math>iwhilej>aandprec(j,j−1)doswap(j,j−1);j<math>\gets</math>j−1i<math>\gets</math>i+1

This procedure can be used to sort the elements *x*[*a*] through *x*[*b*] of some array *x*, of arbitrary type, in a user-specified order. The parameters *prec* and *swap* should be two functions, defined by the client, both taking two integers *r*, *s* between *a* and *b*. The *prec* function should return **true** if and only if the data stored in *x*[*r*] should precede the data stored in *x*[*s*], in the ordering defined by the client. The *swap* function should exchange the contents of *x*[*r*] and *x*[*s*], and return no result.

By the proper choice of the functions *prec* and *swap*, the same *isort* procedure can be used to reorder arrays of any data type, stored in any medium and organized in any data structure that provides indexed access to individual array elements. (Note however that there are sorting algorithms that are much more efficient than insertion sort for large arrays.)

### Sorting floating-point numbers

For instance, we can sort an array *z* of 20 floating-point numbers, *z*[1] through *z*[20] in increasing order by calling *isort* (1, 20,*zprec*,*zswap*), where the functions *zprec* and *zswap* are defined as

procedurezprec(r,s):return(z[r] <z[s])

procedurezswap(r,s):floatt;t<math>\gets</math>z[r];z[r] <math>\gets</math>z[s];z[s] <math>\gets</math>t

### Sorting rows of a matrix

For another example, let *M* be a matrix of integers with 10 rows and 20 columns, with indices starting at 1. The following code will rearrange the elements in each row so that all the even values come before all odd values:

integeriprocedureeoprec(r,s):return(M[i,r]mod2) < (M[i,s]mod2)procedureeoswap(r,s):integert;t<math>\gets</math>M[i,r];M[i,r] <math>\gets</math>M[i,s];M[i,s] <math>\gets</math>tforifrom 1to10doisort(1, 20, eoprec, eoswap)

Note that the effects of *eoprec* and *eoswap* depend on the row number *i*, but the *isort* procedure does not need to know that.

### Vector-sorting procedure

The following example uses *isort* to define a procedure *vecsort* that takes an integer *n* and an integer vector *v* with elements *v*[0] through *v*[*n*−1] and sorts them in either increasing or decreasing order, depending on whether a third parameter *incr* is **true** or **false**, respectively:

procedurevecsort(n,v,incr):procedurevprec(r,s): ifincrthenreturnv[r] <v[s]elsereturnv[r] >v[s]procedurevswap(r,s):integert;t<math>\gets</math>v[r];v[r] <math>\gets</math>v[s];v[s] <math>\gets</math>tisort(0,n−1,vprec,vswap)

Note the use of nested function definitions to get a function *vprec* whose effect depends on the parameter *incr* passed to *vecsort*. In languages that do not allow nested function definitions, like standard C, obtaining this effect would require rather complicated and/or thread-unsafe code.

## Example: merging two sequences

The following example illustrates the use of procedural parameters to process abstract data structures independently of their concrete implementation. The problem is to merge two ordered sequences of records into a single sorted sequence, where the nature of the records and the ordering criterion can be chosen by the client. The following implementation assumes only that each record can be referenced by a memory address, and there is a "null address" Λ that is not the address of any valid record. The client must provide the addresses *A*, *B* of the first records in each sequence, and functions *prec*, *next*, and *append*, to be described later.

proceduremerge(A,B,prec,nextA,appendA,nextB,appendB):addressini,fin,tini<math>\gets</math> Λ;fin<math>\gets</math> ΛwhileA<math>\neq</math> Λ orB<math>\neq</math> ΛdoifB<math>=</math> Λor(A<math>\neq</math> ΛandB<math>\neq</math> Λandprec(A,B))thent<math>\gets</math>nextA(A)fin<math>\gets</math> appendA(A,fin);ifini<math>=</math> Λthenini<math>\gets</math>finA<math>\gets</math>telset<math>\gets</math>nextB(B)fin<math>\gets</math>appendB(B,fin);ifini<math>=</math> Λthenini<math>\gets</math>finB<math>\gets</math>treturnini

The function *prec* should take the addresses *r*, *s* of two records, one from each sequence, and return **true** if the first record should come before the other in the output sequence. The function *nextA* should take the address of a record from the first sequence, and return the address of the next record in the same sequence, or Λ if there is none. The function *appendA* should append the first record from sequence *A* to the output sequence; its arguments are the address *A* of the record to be appended, and the address *fin* of the last record of the output list (or Λ if that list is still empty). The procedure *appendA* should return the updated address of the final element of the output list. The procedures *nextB* and *appendB* are analogous for the other input sequence.

### Merging linked lists

To illustrate the use of the generic merge procedure, here is the code for merging two simple linked lists, starting with nodes at addresses *R*, *S*. Here we assume that each record *x* contains an integer field *x*.*INFO* and an address field *x*.*NEXT* that points to the next node; where the *info* fields are in increasing order in each list. The input lists are dismantled by the merge, and their nodes are used to build the output list.

procedurelistmerge(R,S):procedureprec(r,s):returnr.INFO<s.INFOprocedurenext(x):returnx.NEXTprocedureappend(x,fin)iffin<math>\neq</math> Λthenfin.NEXT<math>\gets</math>xx.NEXT<math>\gets</math> Λreturnxreturnmerge(R,S,prec,next,append,next,append)

### Merging vectors

The following code illustrates the independence of the generic *merge* procedure from the actual representation of the sequences. It merges the elements of two ordinary arrays *U*[0] through *U*[*m*−1] and *V*[0] through *V*[*n*−1] of floating-point numbers, in decreasing order. The input arrays are not modified, and the merged sequence of values is stored into a third vector *W*[0] through *W*[*m*+*n*−1]. As in the C programming language, we assume that the expression "&*V*" yields the address of variable *V*, "**p*" yields the variable whose address is the value of *p*, and that "&(*X*[*i*])" is equivalent to "&(*X*[0]) + *i*" for any array *X* and any integer *i*.

procedurearraymerge(U,m,V,n,W):procedureprec(r,s):return(*r) > (*s)procedurenextU(x):ifx= &(U[m−1])thenreturnΛelsereturnx+ 1procedurenextV(x):ifx= &(V[n−1])thenreturnΛelsereturnx+ 1procedureappend(x,fin)iffin<math>=</math> Λthenfin<math>\gets</math> &(W[0]) (*fin) <math>\gets</math> (*x)returnfin+ 1ifm= 0 thenU<math>\gets</math> Λifn= 0 thenV<math>\gets</math> Λreturnmerge(U,V,prec,nextU,append,nextV,append)

## Example: Definite integral

### Integrating over an interval

The following procedure computes the approximate integral <math>\textstyle\int_a^b</math> *f* (*x*) d*x* of a given real-valued function *f* over a given interval [*a*,*b*] of the real line. The numerical method used is the trapezium rule with a given number *n* of steps; the real numbers are approximated by floating-point numbers.

procedureIntg(f,a,b,n):floatt,x,s;integeriifb=athenreturn0x<math>\gets</math>a;s<math>\gets</math>f(a)/2;forifrom1ton−1dot<math>\gets</math>i/(n+1);x<math>\gets</math> (1−t)*a+t*b;s<math>\gets</math>s+f(x)s<math>\gets</math>f(b)/2return(b−a)*s/n

### Integrating over a disk

Consider now the problem of integrating a given function *g*, with two arguments, over a disk *D* with given center (*xc*,*yc*) and given radius *R*. This problem can be reduced to two nested single-variable integrals by the change of variables

- <math>\int\!\int_D g(x,y)\, \mathrm{d}x\, \mathrm{d}y = \int_0^R z \left(\int_0^{2\pi} g(\mathit{xc}+z \cos t ,\mathit{yc}+z \sin t ) \,\mathrm{d}t\right)\,\mathrm{d}z</math>

The following code implements the right-hand-side formula:

procedureDiskIntg(g,xc,yc,R,n)proceduregring(z):proceduregpolar(t):floatx,yx<math>\gets</math>xc+z*cos(t)y<math>\gets</math>yc+z*sin(t)returng(x,y)integerm<math>\gets</math>round(n*z/R)returnz*Intg(gpolar, 0, 2*π,m)returnIntg(gring, 0,R,n)

This code uses the integration procedure *Intg* in two levels. The outer level (last line) uses *Intg* to compute the integral of *gring*(*z*) for *z* varying from 0 to *R*. The inner level (next-to-last line) defines *gring*(*z*) as being the line integral of *g*(*x*,*y*) over the circle with center (*xc*,*yc*) and radius *z*.

## History

Procedural parameters were invented before the age of electronic computers, by mathematician Alonzo Church, as part of his lambda calculus model of computation.

Procedural parameters as a programming language feature were introduced by ALGOL 60. In fact, ALGOL 60 had a powerful "call by name" parameter-passing mechanism that could simplify some uses of procedural parameters; see Jensen's Device.

Procedural parameters were an essential feature of the LISP programming language, which also introduced the concept of function closure or funarg. The C programming language allows function pointers to be passed as parameters, which accomplish the same end, and are often used as callbacks in event-driven programming and as error handlers. However, only a few modern C compilers allow nested function definitions, so that its other uses are relatively uncommon. Procedural parameters were provided also in Pascal, together with nested procedure definitions; however, since standard Pascal did not allow separate compilation, the feature was little used in that language, too.