Lambda Binding of Arguments in Programs and Functions

Functions and programs have the following general behavior. In their definition, there is a set of formal arguments which are names. For example, if we define the the squaring function:

make sq(x) x^2, or sq(x) := x^2

the x is the single formal argument.

If we define the Logo program that draws a square of side length n, color c:

program drawsquare (ex n) (ex c) {

set pencolor to c;

repeat 4

{

forward n;

rotate 90;

}

}

The names n and c are formal arguments for drawsquare. These formal arguments are used as alias for the actual arguments, which will be supplied in the program or function statement. For example in sq( sqrt(10) ) the actual argument is sqrt(10). In drawsquare( 7+ new, red), the actual arguments are 7+new and red.

The values of these actual arguments are substituted for the formal arguments wherever the latter appear in the body of the definition, and then the body is executed. This raises the delicate question: what if the formal arguments themselves had values. They might be global values, or they might be values assigned by this binding scheme itself. Suppose for example, that n had the value 10 before the statement drawsquare(5,red) was executed. What would be the value of n afterwards? Well, it should be 10 (not 5).

And this is what lambda-binding guarantees. When a program or function statement is executed, the current values of formal parameters are saved (on the stack) and within the scope of the statement, they are bound to the values of the actual arguments made in the call. When the statement is exited, the original values of those formal arguments are restored. This protocol is fully recursive. If within the body of a statement, something is done that causes the formal parameters to be bound again, to new values, the lambda-binding scheme guarantees that this will all happen in an orderly manner.

Now commands do not use lambda binding, they use lexical binding. This is because commands treat their arguments in a much more flexible way than programs and functions do. In commands, the actual arguments are simply substituted lexically for their occurrences in the body of the command. There is no binding of these arguments, and no later unbinding. The disadvantage to this is that the substitutions are made only within the lexical scope (the actual text) of the command body. Other functions or commands that might be invoked by the command statement do not have these parameters bound to the actual arguments supplied with the call in this way. But since commands are designed to be used interactively, this is the intuitive behavior, and usually causes no problems.