Parameters are a way of allowing the same sequence of commands to operate on different data without re-specifying the instructions.

For example, take the following list of instructions:

1. Take an object.
2. Break it into little pieces.
3. Throw it away.

In this case, the object that the instructions are to operate on is the parameter. If we give this process a name like Destroy, then referring to Destroy followed by the desired object will perform the actions on that object.

For instance:

1. Destroy rock.
2. Destroy cake.
3. Destroy car.

will apply the instructions above to a rock, cake, and car respectively.

The sequence of instructions is usually made into a subprogram and the object to operate on is specified while invoking the subprogram. The actual value given to a subprogram while invoking it (that is, rock, cake, or car) is called an actual parameter or an argument and the placeholder within the subprogram used to describe the operations on the argument is called a formal parameter or simply a parameter.

Calling conventions

Parameters can be passed to subprograms in several ways:

• In the call-by-value mechanism, a copy of each parameter is passed to the subprogram. If the subprogram modifies a parameter, it is merely modifying its own copy. Therefore, such modifications are not "visible" to the caller, in the sense that the caller's copy of that datum is unaffected. Since this mechanism only copies data from the caller, the actual parameter can be any expression.

• In the call-by-result mechanism, the parameter is not initialized at the start of the subprogram, and its value at the end of the subprogram is copied back into the caller's copy of the parameter. Since this mechanism copies data to the caller, the actual parameter must be an lvalue.

• In the call-by-reference mechanism, the caller passes a reference to each parameter. This means the caller and the subprogram are both manipulating the same datum, so when such a subprogram modifies one of its parameters, the modification is visible from the caller's perspective as well. Call-by-reference can be simulated in some call-by-value languages like C via pointers: each pointer behaves like a reference to some datum, and while changes to the pointer itself are not visible by the caller (because the pointer was passed by value), modifications to the referenced datum are visible. Since both the caller and subprogram manipulate the same datum, the parameter must be an lvalue.

• In the call-by-copy-restore mechanism, a copy of each parameter is passed to the subprogram. After the subprogram finishes execution, the values of the parameters are copied back to the caller's copy of that datum. This may not have the same effect as call by reference in multi-threaded programs, if another thread accesses the parameter while the subprogram is still executing in a thread. Similar to the call-by-result mechanism, call-by-copy-restore requires an lvalue. This mechanism is also known as call-by-value-result.

• In the call-by-macro-expansion mechanism, the names of formal parameters in the subprogram are substituted by the names of actual parameters in the caller. This can result in the problem of name capture , as demonstrated below:

       swap (a, b)
       {
          tmp = a;
          a = b;
          b = tmp;
       }

When swap (x, tmp) is called by macro-expansion (where x has the value 42 and tmp has the value 64), the effect is for the caller to execute the following:

       tmp = x;
       x = tmp;
       tmp = tmp;

This places the value 42 in both x and tmp.

Actual parameters in call-by-macro-expansion do not necessarily need to be lvalues, but errors may occur with certain usages if they are not.

• In the call-by-name mechanism, any expression passed as a parameter is not evaluated until it is used in the subprogram. At each point it is used, it is evaluated and the resulting value substituted. The subprogram may also modify data if the evaluated expression is an lvalue.

Call by name may also not have the same effect as call by reference or copy-restore, as can be seen by the following example:

       swap (a, b)
       {
          tmp = a;
          a = b;
          b = tmp;
       }

When swap (i, a[i]) is called by name (where a[i] represents the ith element of an array a), if i happens to have the value 9, what happens is the following:

• After tmp = a, tmp becomes 9.
• After a = b, a (which evaluates to i) gets the value stored in a[9] and hence i also gets that value.
• In b = tmp, b evaluates to a[i] but by now i has the value stored in a[9]. Hence a[a[9]] is modified and not a[9] as intended. On the other hand call by reference and by copy-restore would both correctly swap the values stored in i and a[i].

As with call-by-macro-expansion, call-by-name parameters do not necessarily need to be lvalues, but depending on the usage, problems may occur if they are not.

• The call-by-need mechanism is similar to call-by-name, but each of the actual parameters is evaluated when first used and the resulting value is substituted for all subsequent uses of the formal parameter in the subprogram. As with call-by-macro-expansion, call-by-need parameters do not necessarily need to be lvalues, but depending on the usage, problems may occur if they are not.

• The call-by-push-value (CBPV) synthesis, inspired by monads, claims to surprisingly subsume call-by-name and call-by-value by using the paradigm a value is, a computation does.

On a more conceptual level, one may distinguish between parameters for input, for output or both. Virtually all older programming languages regard output and both as identical, but more modern languages such as C# make a distinction.

On the technical level, input parameters are implemented as by value, while the other two types are implemented as by reference.